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EXECUTIVE  SUMMARY  AND  RECOMMENDATIONS 


The  Navy  Occupational  Health  Information  Management  System  (NOHIMS)  was 
tested  and  eva1uated  under  Phase  II  of  a  Department  of  Defense  Small  Business 
Innovation  Research  award  over  the  period  September  1985  through  February  1986. 

A  prototype  version  of  NOHIMS  was  implemented  at  two  industrial  sites — the  Naval 
Air  Rework  Facility  (NARF)  and  Occupational  Health  Unit  (OHU),  North  Island,  San 
Diego,  California,  and  the  Puget  Sound  Naval  Shipyard,  Bremerton,  Washington. 

The  evaluation  team  conducted  extensive  interviews  with  the  users  of  the 
prototype  system  at  the  NARF  and  the  Puget  Sound  Naval  Shipyard,  and  with  Navy 
management  involved  with  the  system,  the  developers  of  the  system,  and 
additional  other  people  having  contact  or  potential  contact  with  the  system.  In 
addition,  resource  materials  on  NOHIMS,  such  as  OPNAVINST  5100. 23B,  the  NOHIMS 
MENS,  the  NOHIMS  System  Decision  Paper,  the  Battelle  Conference  Proceedings 
(June  1979),  the  NOHIMS  documentation,  and  various  published  articles  were 
reviewed.  The  medical  component  software  we  evaluated  consisted  of  COSTAR — the 
Computer  Stored  Ambulatory  Record  which  had  been  customized  to  the  needs  of 
NOHIMS.  We  also  evaluated  Version  1.0  of  the  industrial  component  software. 
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FINDINGS  '  '  1 

Based  on  this  extensive  review  of  materials  and  the  interview  process,  the 
evaluation  team  reports  findings  in  four  major  areas:  realization  of  system 
objectives,  operational  testing,  administrative  deficiencies,  and  requested 
enhancements. 

Realization  of  System  Objectives 

In  its  present  form,  NOHIMS  has  the  potential  to  meet  and  surpass  both  the 
goals  required  by  Navy  directives  and  the  goals  of  the  system  developers  and 
system  users.  NOHIMS  provides  almost  all  of  the  system  functions  as  mandated  by 
the  stated  Navy  goals  for  the  system  including  workplace  monitoring,  hazard 
surveillance,  medical  monitoring,  administrative  reporting,  legal  evidence,  and 
epidemiologic  research.  NOHIMS,  however,  does  need  capability  to  retrieve 
historical  workplace  monitoring  data,  to  enter  injury  and  illness  care  data,  and 
a  statistical  capability.  NOHIMS  has  limited  abilities  to  process  management 
data. 


The  system  has  been  judged  by  the  users  to  be  very  user  friendly, 
relatively  easy  to  learn  and  use,  useful  in  their  daily  work  tasks,  and 
generally  very  suitable  for  Navy  information  needs.  All  of  the  users  were  very 
positive  about  the  general  performance  of  NOHIMS.  The  evaluation  team  was 
impressed  by  the  users'  enthusiasm  for  the  system  despite  the  fact  that  the 
users  were  often  only  aware  of  or  using  a  fraction  of  the  system's  capabilities. 
The  users  and  system  developers  felt  that  the  benefits  of  NOHIMS  were  great  and 
that  it  will  have  a  major  beneficial  impact  on  occupational  health  at  Navy 
industrial  sites. 


I-.,,  .<  ,/pUJOYtd 
■je’-fj;  its 


The  users  and  system  developers  generally  felt  that  NOHIMS  will  be 
adaptable  to  other  Navy  industrial  sites  provided  that  adequate  manpower 
resources  and  training  are  available  for  the  new  sites.  The  design  of  the 
system  is  highly  compatible  with  the  Navy  objective  of  transferability  because 
there  is  a  high  degree  of  inherent  flexibility  in  the  data  collection  and 
storage  processes  within  both  the  industrial  and  medical  components.  Also,  both 
system  components  contain  an  extensive  amount  of  intrinsic  user  help,  a 
necessary  component  for  easy  transferability  of  the  system. 

Operational  Testing 

The  evaluation  team  found  few  operational  deficiencies  in  NOHIMS.  The 
system  is  stable  at  both  test  sites  and  the  majority  of  system  users  are 
satisfied  with  system  performance.  For  the  most  part,  they  rated  NOHIMS  as 
being  acceptable  in  its  present  state.  Generally,  NOHIMS  provided  users  with 
the  information  and  functions  required  and  performed  these  functions  in  a  timely 
and  appropriate  manner.  Areas  of  dissatisfaction  for  NARF  users  included 
occasional  slow  response  time  and  problems  with  communications  equipment.  These 
were  mostly  a  function  of  the  fact  that  NOHIMS  was  resident  on  a  computer  that 
was  used  for  many  other  developmental  purposes  and  was  at  a  remote  location 
necessitating  use  of  telephone  lines  to  connect  users  to  the  mainframe.  Users 
at  the  Puget  Sound  Naval  Shipyard  reported  some  hardware  problems  mostly  during 
initial  implementation  and  occasional  slow  response  time. 

Extensive  system  testing  against  both  the  functional  description  of  the 
system  and  against  the  user  documentation  showed  that  all  modules  were  fully 
operational  and  that  the  documentation,  with  a  few  very  minor  exceptions, 
adequately  and  accurately  described  the  system  operation.  The  exceptions 
included  items  such  as  options  in  the  medical  component  of  NOHIMS  that  were  not 
initialized  and  should  therefore  be  eliminated  from  the  option  menus  and  minor 
inconsistencies  in  the  documentation  instructions.  These  problems  are  not 
design  flaws,  but  rather  represent  "fine-tuning"  of  the  system  requiring  simple 
changes  to  either  the  system  or  to  the  documentation.  We  also  feel  that  it 
would  be  helpful  to  the  user  if  examples  were  added  to  the  documentation  for  the 
industrial  component. 

The  evaluation  revealed  that  the  medical  component  directory  contains  a 
code  for  ethnicity  and  the  codes  for  a  comprehensive  occupational  history  and  a 
medical  history,  although  the  ethnicity  data  item  and  the  history  forms  have  not 
been  accepted  as  part  of  the  prototype  forms  at  the  Occupational  Health  Unit. 
Thus,  these  areas  of  data  collection  still  need  to  be  implemented  in  some  form. 

Administrative  Deficiencies 

The  major  problems  that  we  found  during  the  evaluation  of  NOHIMS  were 
administrative  deficiencies  revolving  around  the  implementation  of  the  system. 
These  problems  are  not  inherent  to  the  NOHIMS  design  but  have  arisen  as  the 
system  has  been  put  into  operational  use.  These  problems  have  been  in  the  areas 
of  training,  manpower,  source  data,  and  paperwork. 

Nearly  all  the  users  that  were  interviewed  felt  that  they  had  received 
inadequate  training  in  the  use  of  NOHIMS  and,  therefore,  often  did  not  feel 
comfortable  with  all  aspects  of  the  system.  In  many  instances,  users  were 
unaware  of  the  full  capabilities  of  the  system.  In  other  areas,  users  were 
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aware  of  certain  system  functions,  but  had  never  or  rarely  used  these  functions. 
System  users  often  had  a  limited  understanding  of  potential  applications  for  the 
system,  such  as  generating  dat^  for  administrative  reports;  thus,  NOHIMS  was  not 
fully  integrated  into  the  workloads  at  the  various  sites.  This  deficiency 
seemed  to  be  more  true  of  the  users  of  the  medical  component  than  of  the 
industrial  component,  perhaps  owing  to  the  fact  that  the  industrial  component 
has  been  operational  for  a  longer  period  of  time.  Remarkably,  despite 
inadequate  training  and  a  limited  understanding  of  the  system's  capabilities, 
the  users  were  all  very  enthusiastic  about  NOHIMS  and  its  potential  benefits  for 
occupational  health.  It  should  be  noted  that  the  system  developers  were  not 
specifically  tasked  with  providing  training;  therefore,  system  users  received 
minimal  training  in  operating  NOHIMS.  The  Naval  Health  Research  Center  (NHRC) 
played  a  greater  role  in  training  users  at  the  Occupational  Health  Unit,  but  the 
NOHIMS  implementers  at  NHRC  were  themselves  at  this  time  learning  the  system. 

One  of  the  reasons  why  users  were  not  fully  aware  of  NOHIMS  capabilities 
was  because  they  did  not  have  adequate  time  allotted  in  their  work  schedule  for 
learning  and  using  the  system.  Although  users  felt  that  NOHIMS  made  them  more 
productive  and  efficient  in  their  work,  NOHIMS  often  added  tasks  to  their 
workload  (e.g.,  entering  data,  completing  data  collection  forms,  etc.).  In 
addition,  NOHIMS  now  made  deficiencies  in  their  workscope,  such  as  inadequate 
sampling  of  environments  or  insufficient  numbers  of  protective  equipment 
examinations,  more  obvious.  Thus,  NOHIMS  increased  the  workload  of  the 
workplace  and  medical  monitoring  personnel  by  bringing  the  programs  more  in  line 
with  mandated  requirements.  When  users  were  asked  what  problems  they  foresee 
when  NOHIMS  is  transferred  to  other  industrial  sites,  many  people  felt  that  the 
transfers  will  not  be  successful  if  the  Navy  does  not  provide  adequate  manpower 
resources  for  NOHIMS.  It  is  clear  from  the  experience  at  the  test  sites  that  if 
sufficient  numbers  of  billets  to  operate  NOHIMS  and  to  allow  for  maximum 
utilization  of  the  system  are  not  allocated,  the  effectiveness  of  NOHIMS  as  an 
occupational  health  information  management  system  will  be  diluted. 

Inaccurate  and  incomplete  source  data  created  problems  in  the  industrial 
component.  The  personnel  module  of  the  industrial  component  depends  on  the 
Personnel  Extract  File  (PEF)  produced  by  the  NARF  Personnel  Department  to  update 
personnel  data  and  assign  workers  to  the  proper  environments.  Inaccurate 
information  in  the  PEF  producing  subsequent  inaccuracies  in  NOHIMS  has  been  a 
major  performance  flaw.  The  design  concept  of  transferring  data  from  the  PEF  to 
NOHIMS  is  adequate;  however,  NOHIMS  will  only  be  able  to  produce  data  as 
accurate  and  complete  as  what  are  fed  into  it. 

Medical  users  complained  about  the  increase  in  paperwork  required  by 
NOHIMS.  As  of  the  time  of  the  interviews,  the  Occupational  Health  Unit  was 
required  to  complete  the  NOHIMS  data  collection  forms  in  addition  to  the 
standard  Navy  medical  forms.  This  requirement  necessitated  a  significant 
increase  in  the  amount  of  time  involved  to  record  the  results  of  a  physical 
examination  both  for  the  physician  and  for  the  occupational  health  technician. 
Also,  because  the  NOHIMS  forms  are  not  accepted  as  the  standard  medical  record 
and  because  the  NOHIMS  prototype  forms  are  bulky,  the  NOHIMS  data  collection 
forms  are  not  stored  with  the  medical  record,  necessitating  additional  storage 
for  the  forms.  The  summary  reports  generated  by  NOHIMS  are  not  reproductions  of 
the  standard  medical  forms,  and  therefore,  have  limited  usefulness  as  a  medical 
record.  The  paperwork  increase  was  not  noticed  by  the  industrial  component 
users  at  the  NARF  because  the  NOHIMS  forms  have  been  accepted  as  the  standard 
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industrial  hygiene  data  collection  forms  for  the  entire  San  Diego  region.  Puget 
Sound  users  reported  a  slight  increase  in  paperwork,  but  felt  that  the  increase 
was  acceptable. 

Requested  Enhancements 

The  NOHIMS  users  requested  three  major  enhancements  to  NOHIMS.  Both 
industrial  and  medical  users,  and  system  developers  requested  a  more 
sophisticated  data  retrieval  system.  The  system's  current  capabilities  are 
quite  extensive,  but  users  requested  interfaces  with  statistical  packages. 

While  data  are  stored  historically  in  the  industrial  component  of  NOHIMS,  NOHIMS 
lacks  the  function  to  retrieve  the  historical  data.  Also,  the  mechanisms  to 
retrieve  correlated  data  from  both  the  industrial  and  medical  components  are 
very  limited. 

Several  of  the  industrial  hygienists  would  like  to  have  the  Hazardous  Agent 
Table  expanded  to  include  hazardous  product  names  to  aid  in  looking  up  agents. 
The  industrial  component  of  NOHIMS  has  a  function  that  will  allow  new  agents  and 
names  to  be  added  to  the  table,  but  the  update  that  the  hygienists  want  would 
require  tremendous  personnel  resources  for  data  entry.  They  also  wanted  the 
software  to  be  modified  to  allow  all  data  in  the  Material  Safety  Data  Sheet  to 
be  included  for  each  agent  in  the  table.  If  these  data  were  added  to  NOHIMS, 
the  system  could  replace  many  of  their  other  reference  materials  such  as  CHEM- 
LINE. 

The  Navy  managers  interviewed  felt  that  the  omission  of  data  collection 
instruments  for  the  walk-in  side  of  the  Occupational  Health  Unit  (OHU)  was  a 
major  weakness  of  NOHIMS.  Because  of  the  inherent  flexibility  of  the  NOHIMS 
directories,  there  is  no  system  limitation  on  including  this  portion  of  the  OHU 
data  in  NOHIMS.  Currently,  NHRC  is  designing  prototype  data  collection  forms 
for  the  walk-in  clinic  and  is  integrating  these  data  items  into  NOHIMS. 


RECOMMENDATIONS 

Based  on  a  thorough  analysis  of  the  comments  and  suggestions  of  those 
interviewed,  the  evaluation  team  makes  the  following  14  recommendations 
concerning  NOHIMS. 

1.  Adequate  configurations  of  hardware  should  be  procured  in  order  to 
minimize  downtime  and  maximize  system  performance.  The  Navy 
should  be  prepared  to  adequately  fund  this  aspect  of  NOHIMS  and 
not  compromise  the  performance  of  NOHIMS. 

2.  An  entity  within  the  Navy  should  be  designated  as  being 
responsible  for  performing  the  installation  and  implementation  of 
NOHIMS  at  each  site,  for  maintaining  the  systems  once  they  are 
operational,  and  for  interfacing  with  the  individual  sites  to  be 
certain  that  the  design  of  data  collection  forms  and  use  of  the 
system  is  compatible  with  NOHIMS  and  with  overall  Navy  objectives. 

3.  The  Navy  should  provide  ample  resources  for  extensive  training  of 
system  users.  Because  of  the  inherent  flexibility  and  scope  of 
NOHIMS,  the  system  is  complex.  The  skills  to  effectively  and 
appropriately  utilize  the  system  cannot  be  learned  overnight.  It 


is  essential  that  an  entity  within  the  Navy  be  tasked  with  the 
responsibility  for  this  system  training.  The  personnel 
responsible  for  the  training  should  have  a  thorough  comprehension 
of  the  objectives  of  NOHIMS,  the  system  capabilities  and 
parameters,  and  the  functions  of  the  environments  in  which  NOHIMS 
will  be  implemented.  The  training  provided  by  this  task  force 
must  be  appropriate  for  each  class  of  system  users  (system 
managers,  industrial  hygienists,  professional  medical  personnel, 
ancillary  medical  personnel,  clerical  personnel,  etc.). 

4.  Consideration  should  be  given  to  establishing  NOHIMS  regions.  In 
addition,  we  feel  that  each  region  should  have  a  NOHIMS  system 
manager  who  is  both  intimately  familiar  with  the  capabilities  and 
parameters  of  NOHIMS  and  is  cognizant  of  the  day-to-day  workings 
of  both  the  occupational  health  units  and  the  industrial  hygiene 
divisions.  This  system  manager  would  then  be  able  to  continue  to 
support  users  after  their  initial  training.  Since  he/she  would 
have  an  understanding  of  both  NOHIMS  and  the  working  environments, 
he/she  could  help  the  end  users  to  integrate  NOHIMS  functions  into 
their  daily  work  routine  and  requirements.  Issues  that  could  be 
addressed  by  the  regional  system  manager  include  appropriateness 
of  data  collection  instruments,  coordination  of  unit/department 
objectives  with  overall  Navy  objectives,  system  support, 
integration  of  data  collection  procedures  into  work  flow,  and  use 
of  the  system  to  meet  administrative  requirements  and  to  enhance 
the  quality  of  work  conducted.  In  addition,  the  system  manager 
could  coordinate  a  regional  users'  group  during  at  least  the  first 
year  of  operation  so  that  experiences  with  NOHIMS  would  be  shared 
and  lessons  that  are  learned  would  be  passed  on  to  others  in  the 
region.  The  users'  group  could  be  an  ideal  vehicle  for  ongoing 
support  and  training,  group  problem  solving,  and  disseminating 
information  about  NOHIMS. 

5.  A  local  site  system  manager  should  be  designated  at  each 
implementation  site  to  be  responsible  for  the  coordination  of 
information  between  the  local  site  and  the  regional  and  national 
agencies,  and  between  the  industrial  hygiene  division  and  the 
occupational  health  units.  This  person  would  be  responsible  for 
maintaining  the  integrity  of  that  site's  database  and  would  be  the 
first  line  of  support  for  the  end  users  of  the  system.  In  the 
first  phases  of  implementation  we  see  this  task  as  being  quite 
time-consuming,  although  the  demands  will  lessen  as  users  become 
familiar  with  the  system  and  the  site  passes  from  the 
implementation  and  testing  phase  to  the  operational  phase. 

6.  It  is  essential  that  there  be  adequate  dialogue  between  the  Navy 
NOHIMS  technical  experts  and  the  medical  personnel  at  each 
industrial  site  to  insure  that  t he  data  collection  forms  are  both 
useful  to  and  appropriate  for  t  tie  occupational  health  unit  and 
compatible  with  the  system  parameters  oT  the  medical  component  of 
NOHIMS  and  the  intended  future  uses  of  the  NOHIMS  database.  If 
knowledgeable  decisions  about  data  collection  are  not  made  at  the 
beginning,  the  usefulness  of  the  database  for  future  analysis  and 
functionality  of  the  data  collection  forms  may  be  compromised. 
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7.  Adequate  billets  should  be  allotted  for  departments  receiving 
NOHIMS  to  allow  for  the  time  required  to  learn  and  use  NOHIMS  and 
for  the  increased  workload  that  will  result  from  having  workplace 
and  medical  monitoring  programs  that  more  stringently  meet  Navy 
standards.  As  stressed  in  our  summary,  if  NOHIMS  is  not  given 
priority  to  receive  adequate  resources,  the  usefulness  of  the 
system  to  the  end  user  will  be  greatly  limited.  If  NOHIMS  is 
regarded  as  merely  a  collateral  duty,  the  users  may  come  to  resent 
the  additional  responsibilities  that  NOHIMS  brings,  ultimately 
hindering  the  acceptance  of  NOHIMS. 

8.  The  billets  for  each  site  receiving  NOHIMS  should  include  a  billet 
for  a  data  entry  clerk  for  both  the  medical  and  industrial 
components.  The  North  Island  test  site  does  not  have  a  data  entry 
billet  for  the  industrial  hygiene  division;  instead  industrial 
hygienists  enter  the  survey  data  themselves.  The  consequence  is 
that  they  are  behind  on  survey  data  entry  and  the  number  of 
surveys  the  hygienists  are  able  to  perform  is  decreased.  The 
Puget  Sound  Naval  Shipyard,  on  the  other  hand,  has  a  billet  for 
data  entry.  A  data  clerk  who  does  data  entry  half-time  keeps  the 
survey  data  entered  up  to  the  minute,  thereby  increasing  the 
effectiveness  of  that  industrial  hygiene  division. 

9.  When  the  additional  personnel  are  added  to  the  NOHIMS  sites,  it  is 
essential  that  site  management  distribute  the  workload  evenly 
among  personnel  so  that  all  personnel  are  freed  up  to  spend  some 
time  working  with  NOHIMS.  It  would  be  easy  to  use  the  additional 
billets  for  direct  patient  care  or  for  industrial  hygiene 
activities;  however,  it  is  our  belief  that  providing  time  for 
working  with  NOHIMS  will  be  a  better  way  to  ultimately  improve  the 
quality  of  occupational  health  care  provided  to  the  workers  at 
each  industrial  site. 

10.  NOHIMS  data  collection  forms  and  NOHIMS  generated  reports  should  be 
accepted  in  lieu  of  the  standard  Navy  medical  record  and  reports  in 
order  to  lessen  the  workload  for  occupational  health  personnel  and 
to  decrease  the  amount  of  paperwork  and  storage  required  for  the 
paperwork.  If  the  standard  NOHIMS  reports  are  deemed  to  be 
insufficient  for  Navy  records,  then  the  capability  of  producing 
facsimile  reports  and  records  from  NOHIMS  should  be  added  to 
NOHIMS. 

11.  The  Navy  needs  to  create  explicit  policy  guidelines  for  the  data 
collection  forms  to  ensure  that  a  minimum  standard  set  of  data  is 
collected  so  that  Navy-wide  data  analysis  may  be  conducted.  The 
compatibility  of  the  directories  between  systems  must  also  be 
preserved.  To  help  accomplish  this,  we  recommend  that  the 
industrial  sites  not  have  access  to  the  system  maintenance 
functions  for  the  directories;  rather  a  central  entity  would  have 
the  responsibility  for  maintaining  the  directories.  As  the 
directories  may  not  contain  all  data  items  that  each  occupational 
health  unit  or  industrial  hygiene  division  may  desire,  the  central 
entity  should  establish  a  mechanism  whereby  the  central  entity 


would  properly  add  new  items  to  the  directories  as  required.  It  is 
our  understanding  that  the  prototype  data  collection  forms 
(especially  the  medical  and  occupational  history  forms)  that  were 
developed  by  the  North  Island  Occupational  Health  Unit  are  being 
reviewed  by  other  potential  users  to  determine  if  they  will  be 
adequate  for  other  occupational  health  units  in  the  Navy.  The 
results  of  this  review  will  determine  whether  the  current  medical 
directory  will  be  adequate  for  other  industrial  sites. 

12.  Adequate  administrative  instruction  and  resources  should  be 
provided  to  the  personnel  departments  at  the  industrial  sites  to 
insure  that  the  Personnel  Extract  File  is  accurate,  complete,  and 
timely,  thereby  insuring  the  integrity  of  the  personnel  data  in  the 
NOHIMS  database. 

13.  The  few  minor  inconsistencies  between  the  system  documentation  and 
NOHIMS  operation  should  be  corrected.  If  resources  are  available, 
examples  should  be  added  to  the  industrial  component  documentation. 

14.  Additional  resources  should  be  provided  to  enhance  the  system  as 
requested  by  the  system  developers  and  users.  Most  of  the 
enhancements  suggested  by  the  system  developers  and  users  are 
reasonable  requests  and  if  added  to  the  system  would  increase  the 
effectiveness  of  NOHIMS.  These  include  a  statistical  interface 
between  the  database  and  a  MUMPS-based  statistical  package,  the 
capability  of  retrieving  historical  data  from  the  industrial 
component,  the  capability  of  retrieving  correlated  data  from  both 
the  industrial  and  medical  components,  the  development  of  data 
collection  forms  and  directory  codes  for  injury  and  illness  care 
provided  by  the  Occupational  Health  Unit,  and  a  software 
modification  to  add  further  detail  to  the  Hazardous  Agent  Table. 

The  statistical  interface  could  either  be  developed  from  scratch  or 
NOHIMS  could  be  linked  with  existing  statistical  software  such  as 
MEDINFO,  BMD,  SPSS,  and/or  SAS.  Additional  programs  will  need  to 
be  written  to  retrieve  historical  data  from  the  industrial 
database.  The  limitations  on  retrieving  correlated  data  from  both 
components  could  possibly  be  overcome  by  integrating  the  Medical 
Query  Language  (MQL)  with  NOHIMS  and  using  it  to  select  attributes 
of  interest  from  the  two  components  and  then  to  interrelate  these 
data  items.  NHRC  is  currently  developing  data  collection  forms  and 
directory  codes  for  the  walk-in  clinic  at  the  North  Island  OHU  to 
meet  that  requested  enhancement.  The  Hazardous  Agent  Table  should 
be  modified  so  that  all  of  the  items  on  the  Material  Safety  Data 
Sheet  can  be  included  in  the  table.  Since  NOHIMS  already  contains 

a  large  number  of  agents  and  new  agents  may  be  added  to  the 
Hazardous  Agent  Table  as  needed,  we  feel  that  the  current  HAZARD 
DATA  module  is  adequate.  As  to  adding  the  agents  found  in 
resources  such  as  CHEM-LINE,  we  recommend  that  the  Navy  explore  the 
need  for  these  data  further  before  additional  personnel  resources 
are  allocated  for  the  data  entry  task.  The  NOHIMS  contracted 
developers  also  recommend  that  NOHIMS  be  enhanced  with  certain 
routines  from  COSTAR  Version  3.81  (such  as  the  routines  for  the 
stand-alone  Mailbox  module)  to  provide  special  features  not 
available  in  previous  versions  of  COSTAR. 
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SECTION  I 
INTRODUCTION 


The  Navy  Occupational  Health  Information  Management  System  (NOHIMS)  has 
been  undergoing  design  and  development  by  the  Naval  Health  Research  Center 
(NHRC),  San  Diego,  California  since  early  1980.  NOHIMS  consists  of  two 
subsystems:  (1)  an  industrial  component  and  (2)  a  medical  information 

component.  The  industrial  component  (Version  1.0)  performs  all  the  functions 
required  to  identify  individuals  at  risk  and  to  insure  that  they  are  examined 
periodically.  Therefore,  the  industrial  subsystem  contains  the  personnel  and 
environmental  data.  The  medical  information  component  consists  of  COSTAR — the 
Computer  Stored  Ambulatory  Record  system.  Each  of  these  two  components  of 
NOHIMS  can  operate  as  a  stand-alone  system,  or  they  can  function  as  a  single, 
integrated  system  because  both  components  use  the  same  system  conventions 
wherein  users  interact  with  the  database  at  increasing  levels  of  specificity  by 
making  choices  from  a  hierarchical  series  of  option  menus.  In  addition,  both 
components  incorporate  extensive  user  help,  aids,  and  explanation  techniques. 

The  prototype  version  of  NOHIMS  has  been  tested  and  evaluated  by  NHRC  at 
two  industrial  sites — the  Naval  Air  Rework  Facility  (NARF)  and  Occupational 
Health  Unit  (OHU),  North  Island,  San  Diego,  California  and  the  Puget  Sound  Naval 
Shipyard,  Bremerton,  Washington.  Both  the  industrial  and  medical  information 
components  of  NOHIMS  have  been  implemented  at  the  North  Island  site;  to  date 
only  the  industrial  component  has  been  implemented  at  the  Puget  Sound  Naval 
Shipyard.  Table  and  file  building  for  the  industrial  component  at  the  North 
Island  NARF  began  in  December  1983  and  is  now  complete,  with  industrial  data 
currently  being  entered  routinely.  The  medical  information  component  was  phased 
into  work  routines  at  the  North  Island  Occupational  Health  Unit  beginning  in 
July  of  1984. 

As  part  of  the  implementation  effort  at  the  North  Island  site,  a  series  of 
encounter  forms  were  developed  to  capture  the  required  medical  data.  A  User  s 
Reference  Manual  for  the  medical  component  of  NOHIMS  and  a  variety  of  job  aids 
were  developed  to  facilitate  the  data  entry  process.  A  less  elaborate  user's 
manual  was  developed  for  the  industrial  component  of  NOHIMS  because  this 
component  contains  an  extensive  amount  of  intrinsic  user  help.  These  training 
materials  were  used  to  train  data  entry  clerks,  medical  personnel,  industrial 
hygienists,  and  safety  officers  in  the  use  of  NOHIMS. 

Under  Phase  I  of  a  Department  of  Defense  Small  Business  Innovation  Research 
award,  R-K  Research  and  System  Design  developed  a  Test  and  Evaluation  Master 
Plan  (TEMP)  to  independently  test  and  evaluate  NOHIMS  at  both  the  North  Island 
NARF/OHU  and  the  Puget  Sound  Naval  Shipyard.  The  TEMP  considered  seven  major 
areas  of  system  functioning:  (1)  responsiveness  of  NOHIMS  to  Navy  needs  and 
requirements,  (2)  suitability  of  the  NOHIMS  design,  (3)  efficiency  of  NOHIMS 
performance,  (4)  enhancement  of  medical  monitoring  and  care  by  NOHIMS,  (5)  use 
of  the  NOHIMS  database  for  legal  evidence,  (6)  usability  of  NOHIMS,  and 
(7)  transferability  of  NOHIMS.  It  also  touched  on  NOHIMS  as  an  aid  to 
epidemiologic  research  and  the  costs  versus  benefits  of  the  system.  (These  last 
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two  areas  were  considered  only  briefly  per  direction  of  our  sponsor,  the  Naval 
Medical  Research  and  Development  Command  [NMRDC]). 

The  Test  and  Evaluation  Master  Plan  was  carried  out  in  six  steps: 

1.  The  evaluation  team  interviewed  personnel  involved  in  the 
development  and/or  testing  of  NOHIMS  at  the  Naval  Air  Rework 
Facility  (NARF),  North  Island,  San  Diego,  California  and  the 
Puget  Sound  Naval  Shipyard,  Bremerton,  Washington  test  sites. 

These  personnel  included  people  from  various  divisions  of  the 
Occupational  Health  and  Preventive  Medicine  Department,  San 
Diego,  California;  the  Occupational  Health  Unit,  North  Island, 

San  Diego,  California;  the  NARF  Safety  Office,  North  Island, 

San  Diego,  California;  and  the  Occupational  Health  and 
Preventive  Medicine  Department,  Bremerton,  Washington. 

Individuals  from  other  Navy  entities,  including  the  Navy 
Environmental  Health  Center  (NEHC),  Norfolk,  Virginia;  the 
Naval  Health  Research  Center  (NHRC),  San  Diego,  California;  the 
Injury  Compensation  Program,  Naval  Air  Station/Naval  Air  Rework 
Facility,  North  Island,  San  Diego,  California;  and  the  Naval 
Hospital,  San  Diego  (Balboa)  were  also  interviewed.  We  used 
the  interview  guides  contained  in  Appendix  A  of  this  report  to 
conduct  these  interviews.  Appendix  B  contains  a  list  of  the 
people  who  were  interviewed  and  the  guides  that  we  used  to 
interview  them.  Some  individuals  were  interviewed  with  more 
than  one  interview  guide  if  they  had  multiple  roles  with 
NOHIMS.  The  interviews  at  North  Island  and  other  San  Diego 
locations  were  conducted  from  September  9,  1985  through 
September  24,  1985.  The  interviews  at  the  Puget  Sound  Naval 
Shipyard  were  conducted  from  November  18,  1985  through  November 
20,  1985.  Each  person  was  interviewed  by  at  least  two  members 
of  the  interview  team  so  that  responses  could  be  cross- 
validated.  The  interview  guides  were  not  used  as  a  rigid 
schedule,  but  rather  were  used  to  direct  the  flow  of 
discussion.  We  encouraged  interviewees  to  digress  from  the 
question  at  hand  or  go  into  further  detail  if  it  seemed 
appropriate.  Questions,  and  sometimes  complete  sections,  were 
omitted  if  the  interviewees  could  not  comment  on  that  topic  or 
if  it  was  not  applicable  to  them. 

2.  We  then  collated  the  interviews,  and  the  data  gathered  by  the 
individual  evaluation  team  members  were  compared  to  identify 
any  inconsistencies.  These  inconsistencies  were  resolved 
through  discussion,  or  if  required,  by  follow-up  with  the 
interviewee. 

3.  During  the  development  of  the  TEMP,  we  had  identified  several 
materials  as  resources  for  the  evaluation  of  NOHIMS.  These 
included  OPNAVINST  5100.2313,  the  NOHIMS  MENS,  the  NOHIMS  System 
Decision  Paper,  the  Battel le  Conference  Proceedings  (June, 

1979),  the  NOHIMS  documentation,  and  various  published 
articles.  We  reviewed  these  materials  and  gathered  information 
required  for  the  evaluation  report. 
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4.  To  test  the  operational  characteristics  of  NOHIMS,  we  performed 
two  kinds  of  system  testing.  First,  individuals  unfamiliar 
with  NOHIMS  used  the  NOHIMS  user's  manuals  to  perform  the  tasks 
described  in  the  documentation.  These  tasks  included 
entering  registration  and  medical  data  for  a  patient, 
generating  standard  reports  and  some  typical  user-defined 
reports,  entering  survey  data,  and  looking  up  hazardous  agents. 
Second,  we  performed  various  tasks  related  to  system 
maintenance  and  produced  the  reports  required  by  the  Navy  to 
determine  if  NOHIMS  met  the  Navy's  functional  requirements. 

5.  Next  we  collated  the  information  from  the  interviews  and 
integrated  it  with  the  data  from  the  resource  materials  and 
system  testing  to  produce  a  draft  of  our  Evaluation  Report  for 
review  by  NMRDC.  The  preliminary  outline  of  the  final  report 
produced  during  Phase  I  of  this  project  was  used  as  the  guide 
for  determining  the  contents  of  the  Evaluation  Report. 

6.  Based  on  feedback  from  NMRDC,  we  revised  the  draft  Evaluation 
Report  and  submitted  our  final  Evaluation  Report  as  called  for 
in  Phase  II. 


The  Evaluation  Report  consists  of  nine  sections.  This  Introduction  is 
preceded  by  the  Executive  Summary  and  Recommendations.  Seven  sections,  each  of 
which  covers  an  area  of  the  NOHIMS  evaluation,  follow  the  Introduction.  These 
sections  include  the  evaluation  of  the  goals  of  NOHIMS,  an  evaluation  of  NOHIMS 
system  design,  results  of  operational  testing  of  NOHIMS,  an  evaluation  of  the 
uses  of  NOHIMS,  an  assessment  of  the  transferability  of  NOHIMS  to  other  Navy 
industrial  sites,  a  brief  economic  analysis  of  NOHIMS,  and  a  brief  comparison  of 
NOHIMS  to  other  occupational  health  information  systems. 


SECTION  II 

EVALUATION  OF  NOHIMS  GOALS 


BACKGROUND  OF  NAVY  GOALS  FOR  NOHIMS 

In  1970  Congress  enacted  the  Occupational  Safety  and  Health  Act  (Public  Law 
91-596)  (OSHA)  requiring  all  employers  to  provide  safe  and  healthful  working 
conditions  for  their  employees.  Executive  Order  12196  mandated  that  these 
occupational  health  services  be  applied  to  all  civilian  workers  of  the  Federal 
agencies,  including  the  Department  of  the  Navy.  The  Order  specifically  ordered 
Federal  agencies  to  develop  and  implement  automated  data  processing  applications 
for  OSHA-related  data  needs.  By  authority  of  DODINST  6055.5,  OSHA  standards 
also  were  applicable  to  most  active  duty  military  personnel. 

To  implement  OSHA  in  the  Navy,  the  Secretary  of  the  Navy  and  the  Chief  of 
Naval  Operations  issued  SECNAVINST  5100. 10D,  OPNAVINST  5100. 8E,  and  OPNAVINST 
5100. 23A.  SECNAVINST  5100. 10D  established  the  Department  of  the  Navy 
occupational  safety  and  health  policy  and  assigned  responsibility  for  Navy 
programs.  This  instruction  directs  that  a  "comprehensive,  aggressive,  and 
effective  occupational  safety  and  health  program..."  be  established. 

In  response,  OPNAVINST  5100. 8E  created  the  Navy  Safety  and  Occupational 
Health  (SOH)  program.  This  instruction  specified  that  the  Chief  of  Naval 
Material;  Chief,  Bureau  of  Medicine  and  Surgery;  Chief  of  Naval  Personnel;  and 
the  Commander,  Naval  Safety  Center  were  to  develop  procedures  and  provide 
instructions  for  each  support  area  specified,  and  outlined  the  role  that  each 
activity  was  to  take  in  the  SOH  program. 

OPNAVINST  5100. 23B  established  the  Navy  Occupational  Safety  and  Health 
(NAV0SH)  program,  which  is  somewhat  more  limited  than  SOH.  It  also  established 
the  Navy  Occupational  Safety  and  Health  Inspection  Program  (NOSHIP)  that  employs 
an  Oversight  Inspection  Unit  to  provide  an  inspection  system  covering  the  entire 
NAV0SH  program.  This  instruction  specifically  identified  the  following 
activities:  (1)  "design  and  provide  comprehensive  workplace  monitoring  plans, 

(2)  "develop  and  implement  personnel  medical  surveillance,"  (3)  "provide  other 
industrial  hygiene  and  occupational  health  support,"  (4)  "conduct  annual  audits 
of  each  industrial/operational  activity  workplace  monitoring  program," 

(5)  "provide  training  and  certification  for  command  personnel  assigned  to 
perform  workplace  monitoring,"  and  (6)  "establish  appropriate  records  relating 
to  workplace  monitoring  and  the  comprehensive  occupational  health  program  (Pugh 
&  Beck,  1981).  The  instruction  also  assigned  responsibility  for  the  provision 
of  occupational  health  and  industrial  hygiene  medical  services  to  the  Commander, 
Naval  Medical  Command.  NAVMEDCOMINST  5450.16  delegated  much  of  the  Naval 
Medical  Command  responsibilities  to  the  Naval  Health  Research  Center  (NilRC). 

The  problems  and  strategies  of  implementing  Navy  occupational  health  and 
safety  programs  were  addressed  in  a  conference  on  Navy  occupational  health  held 
at  Battelle  Human  Affairs  Research  Centers,  Seattle,  Washington,  on  January  29- 
30,  1979.  The  purpose  of  this  conference  was  to  provide  a  forum  where  persons 
from  diverse  professional  and  disciplinary  perspectives  could  address  issues  of 


implementing  Navy  occupational  health  and  safety  programs.  The  conference 
objectives  were  to  consider  organizational  factors  in  the  implementation  of  Navy 
occupational  health  programs,  to  address  issues  of  cost  effectiveness  in  Navy 
occupational  health  programs,  and  to  facilitate  the  development  of  a  meaningful 
research  program  in  this  area.  The  conference  itself  was  sponsored  by  the  Naval 
Medical  Research  and  Development  Command  and  by  the  Office  of  Naval  Research. 

It  was  jointly  hosted  by  Battelle  and  by  the  Naval  Health  Research  Center 
(Drexler,  Jones,  &  Gunderson,  1979). 

A  major  conclusion  from  this  conference  was  that  structural  decisions  about 
occupational  health  care  must  be  accompanied  by  effective  information  systems 
that  are  designed  to  meet  both  short-term  and  long-term  needs.  Foremost  among 
shor  -term  needs  were  information  about  type  and  duration  of  exposure  to  hazards 
and  potential  hazards,  evidence  of  compliance  with  standards  and  guidelines,  and 
measures  of  program  effectiveness.  Long-term  needs  were  data  oriented  towards 
the  discovery  of  currently  unrecognized  risks,  portrayal  of  career  profiles,  and 
the  design  of  future  programs;  performance  of  a  wide  variety  of  epidemiological 
tasks;  and  display  of  essential  technical  information  related  to  toxic 
properties  of  chemicals  and  materials  (System  Decision  Paper,  1984;  Drexler, 
Jones,  &  Gunderson,  1979). 

In  1979  it  was  generally  agreed  that  the  establishment  and  implementation 
of  an  effective  Navy  occupational  health  program  would  require  a  clearly  stated 
set  of  occupational  health  goals  and  priorities  to  which  upper-level  managment 
is  firmly  committed  and  which  they  will  support  through  policy  decisions  and 
resource  allocation.  It  was  also  recognized  that  a  systematic  and  integrated 
information  and  monitoring  system  was  an  important  tool  to  be  used  in  obtaining 
necessary  data.  The  system  must  merge  exposure  data,  illness  episodes,  and 
biomedical  hazard  monitoring  data  into  a  single,  usable  information  system  with 
appropriate  storage  and  retrieval  capability.  The  major  conclusion  of  the 
Information  Systems  Topic  Group  of  the  conference  was  that  the  Navy  did  not  have 
a  comprehensive  occupational  health  information  system  that  met  user  needs.  The 
Industrial  Hygiene  Working  Group  reported  a  need  for  the  development  of  an 
effective  information  system  for  providing  guidance  required  in  conducting 
industrial  hygiene  and  occupational  health  programs.  Finally,  the 
Epidemiology/Environmental  Health  Working  Group  stated  a  need  to  develop  a 
computerized  occupational  and  medical  surveillance  system  that  could  serve  as  a 
database  that  is  easily  accessible  and  available  lor  epidemiologic  analyses 
(System  Decision  Paper,  1984;  Drexler,  Jones,  &  Gunderson,  1979). 

In  1980,  after  a  review  of  commercially  available  occupational  health 
information  systems  found  that  these  were  inadequate  for  the  Navy's  needs  and 
requirements,  the  Naval  Health  Research  Center  undertook  the  development  of  an 
occupational  health  monitoring  system.  The  resulting  system  was  named  the  Navy 
Occupational  Health  and  Information  Monitoring  System,  which  was  later  changed 
to  the  Navy  Occupational  Health  and  Information  Management  System  (NOHIMS).  The 
Mission  Element  Needs  Statement  (MENS)  for  NOHIMS  was  approved  by  the  Chief  of 
Naval  Operations  in  February,  1984.  During  that  same  month,  NOHIMS  also 
received  its  project  charter.  The  System  Decision  Paper  was  presented  to  the 
Commander,  Naval  Data  Automation  Command  via  the  Chief  of  Naval  Operations  in 
July,  1984. 

The  NOHIMS  MENS  identified  areas  of  deficiency  or  nonperformance  around 
five  Navy  organizational  levels,  namely,  the  local  occupational  health  clinic, 
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the  local  industrial  hygiene  unit,  the  chiefs  of  occupational  and  environmental 
health  services,  the  Naval  Health  Research  Center,  and  the  Naval  Medical 
Research  and  Development  Command.  The  areas  of  deficiency  for  each  level 
included  the  following. 

Local  Occupational  Health  Clinic 

•  Efficient  provision  of  examinations  for  all  hazards 

•  Prompt  provision  of  worker  exposure  history 

•  Recording  and  transmittal  of  medical  job  certifications  to  line 
authorities 

•  Provision  of  composite  summaries  of  work  force  physical 
examinations 

•  Provision  of  accurate  medical  information  on  individuals  for  legal 
needs 

•  Provision  of  exposure  and  health  data  for  epidemiologic  and 
research  purposes 

•  Provision  of  workload  summaries  to  higher  authorities 
Local  Industrial  Hygiene  Unit 

•  Retrieval  of  exposure  parameters  by  location  or  hazard  type 

•  Provision  of  current  exposure  information  to  medical  personnel  to 
direct  medical  examinations  for  possible  harmful  work  exposure 

•  Furnish  historical  exposure  information  on  individual  workers  or  a 
defined  cohort 

•  Demonstrate  past  and  present  levels  of  workplace  exposures  for 
compliance  with  NAVOSH  standards 

•  Provision  of  accurate  workplace  exposure  data  for  Workers' 
Compensation  or  environmental  differential  pay  determinations 

•  Provision  of  workload  summaries  to  higher  authorities 
Chiefs  of  Occupational  and  Environmental  Health  Services 

•  Tracking  and  direction  of  resource  utilization 

•  Identification  and  prompt  response  to  adverse  workplace  exposures 

•  Identification  and  prompt  response  to  adverse  work-related  health 
trends 

•  Provision  of  summary  data  on  extent  of  disease  and  injury  by  hazard 
type  and  work  location 
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•  Provision  of  summary  medical  and  industrial  hygiene  data  for 
epidemiology,  research,  reports  to  higher  authority,  and 
administrative  proceedings 

Naval  Health  Research  Center 

•  Provision  of  a  consistent,  authoritative,  single  source  for  the 
summary  and  analysis  of  Navy-wide  occupational  health  problems 

•  Access  to  accurate  information  on  which  to  provide  resource 
recommendations  directed  toward  solving  Navy  occupational  health 
issues 

•  Response  to  reports  of  new  or  alleged  occupational  health  hazards 

•  Integration  of  disparate  data  and  performance  of  trend  analysis  of 
events  over  a  prolonged  time  frame 

Naval  Medical  Research  and  Development  Command 

•  Response  to  requests  to  investigate  occupational  health  issues  when 
sufficient  information  is  not  otherwise  available 

•  Performance  of  Navy  occupational  health-related  research, 
development,  and  test  and  evaluation  projects 

The  NOHIMS  System  Decision  Paper  outlined  the  features  of  the  basic 
approach  that  would  be  used  in  developing  and  implementing  NOHIMS  and  defined 
the  general  system  requirements  as  follows. 

Approach  to  NOHIMS 

•  NOHIMS  to  be  used  to  integrate  important  occupational  health  data 
elements  from  industrial  hygiene,  medical,  and  personnel  records 
for  management  and  epidemiologic  purposes 

•  Industrial  hygiene  data  to  include  selected  information  on  work 
environments;  the  full  survey  data  are  kept  in  a  suitable 
noncomputerized  form  and  referenced  in  NOHIMS 

•  Medical  information  to  include  selected  data  from  all  occupational 
health  services,  including  preplacement/employment  physical 
examinations,  medical  surveillance  examinations,  job  certification 
examinations,  injury/illness  care,  fitness  for  duty  and  return  to 
work  interactions,  but  not  to  replace  the  ambulatory  care  record; 
computer-assisted  hard  copy  of  medical  reports  used  where 
possible 


•  Personnel  data  to  be  extracted  from  existing  computerized  databases 
wherever  possible;  compatibility  and  linkage  with  Uniformed  Chart 
of  Accounts,  military  personnel/pay  systems,  TR1MTS,  or  other 
suitable  databases  should  be  actively  explored,  developed,  and 
demonstrated  where  possible;  NOHIMS  medical  files  set  up 


prospectively  for  each  person  served  by  a  clinic  prior  to  any 
health  encounter 


•  NOHIMS  to  incorporate  or  replace  existing  central  Asbestos  Medical 
Surveillance  Program  (AMSP)  and  Hearing  Conservation  Management 
Information  System  (HECMIS)  databases  when  NOHIMS  is  implemented 
Navy-wide;  ability  to  utilize  all  historical  AMSP  and  HECMIS  data 

General  System  Requirements 

•  A  distributed  interactive  network  to  address  needs  of  Navy  health 
providers  and  managers 

•  Ability  to  input,  store,  process,  and  display  occupational  health 
data  to  include  work  history,  exposure  episodes,  audiometric  data, 
biomedical  monitoring  data,  preplacement  and  routine  physicals, 
associated  environmental  monitoring  and  industrial  hygiene  data, 
basic  medical  and  demographic  data,  and  other  information  as 
required  by  the  user 

•  Capability  of  access  to  and  display  of  information  from  intra-  and 
extra-Navy  databases,  such  as  hazardous  material  information 
systems,  and  Federal,  DOD,  or  Navy  standards  and  instructions 

•  Hazard  and  risk  assessment  through  the  performance  of  retrospective 
and  prospective  epidemiologic  investigations  on  medical  record  data 
files 

•  Input,  store,  process,  and  display  occupational  health  program 
management  data  to  include  manpower,  time-in-motion,  equipment 
lists,  inspection  requirements,  and  other  appropriate  resource  data 
required  to  document  current  and  projected  workload,  equipment,  and 
resources  for  manpower  planning  and  budgeting  purposes 

NOHIMS,  then,  came  out  of  a  need  to  coordinate  the  components  of  the  Navy 
Occupational  Safety  and  Health  Program.  The  two  main  goals  of  the  system  were 
to  manage  information  from  the  medical  surveillance  program  and  the  workplace 
monitoring  program.  In  addition,  NOHIMS  would  provide  data  for  a  variety  of 
purposes,  including  management  reports  and  functions,  short-term  and  long-term 
research  activities,  workman's  compensation  and  environmental  pay  decisions,  and 
resource  and  manpower  utilization.  Indirectly  it  would  improve  the  occupational 
health  care  provided  to  the  worker  at  Navy  sites  by  bringing  it  in  line  with 
Navy  Occupational  Safety  and  Health  standards  and  OSHA  directives  of  1970. 


EVALUATION  OF  SYSTEM  GOALS 

From  the  background  information  described  above,  we  compiled  a  list  of 
eleven  goals  for  NOHIMS  for  use  during  the  interviews  of  the  NHRC  NOHIMS 
developers,  higher  level  managers,  test  site  administrators,  and  the  system 
users  in  both  San  Diego,  California  and  Bremerton,  Washington.  These  goals  were 
as  follows. 


'j.l 


i  '  . 


iSf. 


•  Meet  OSHA  requirements 

•  Improve  medical  surveillance 

•  Improve  workplace  monitoring 

•  Provide  data  for  epidemiologic  analysis 

•  Improve  patient  care 

•  Improve  coordination  between  departments 

•  Provide  management  data 

•  Improve  access  to  care 

•  Improve  manpower  utilization 

•  Improve  resources  utilization 

•  Provide  data  for  legal  functions 

Using  this  list  of  goals,  we  asked  the  NHRC  NOHIMS  developers  and  the 
higher  level  managers  to  tell  us  which  of  the  eleven  goals  they  thought  were 
stated  Navy  goals  for  NOHIMS  and  what  their  personal  goals  for  the  system  were. 
We  then  asked  them  to  evaluate  how  well  NOHIMS  was  meeting  each  of  these  sets  of 
goals.  In  almost  every  interview,  the  interviewees  did  not  make  a  distinction 
between  their  understanding  of  the  Navy  goals  and  their  personal  goals  for 
NOHIMS,  so  we  have  presented  only  one  set  of  answers  for  the  NHRC  NOHIMS 
developers  and  Navy  management.  System  users  and  test  site  administrators  were 
asked  to  identify  which  of  the  eleven  were  goals  for  NOHIMS  and  how  well  NOHIMS 
was  meeting  these  goals.  The  questions  that  we  used  for  this  portion  of  the 
interviews  may  be  found  in  Appendix  A,  Components  1  and  2.  If  an  interviewee 
was  required  to  answer  the  questions  about  goals  in  two  interviews,  the  answers 
were  combined  and  included  in  only  one  category  of  the  following  tables.  We 
based  the  category  on  what  was  the  interviewee's  main  function  with  NOHIMS.  The 
difference  between  higher  level  managers  and  test  site  administrators,  as  we 
defined  them,  is  that  the  work  location  of  the  test  site  administrators  is  the 
test  site  and  they  presumably  have  more  first-hand  knowledge  and/or  experience 
with  NOHIMS. 


NHRC  NOHIMS  Developers  and  Higher  Level  Managers 

At  least  three-quarters  of  the  NHRC  NOHIMS  developers/higher  level  managers 
mentioned  the  four  goals  of  improving  medical  surveillance,  meeting  OSHA 
requirements,  improving  workplace  monitoring,  and  providing  data  for 
epidemiologic  analysis.  The  other  goals  were  all  mentioned  by  several  of  the 
developers/managers,  but  to  a  lesser  degree  than  these  four  (see  Table  1).  One 
interviewee  thought  that  NOHIMS  would  be  used  as  a  resource  in  training 
physicians  in  medical  monitoring  (Other  category).  The  goals  noted  by  the  NHRC 
NOHIMS  developers  and  by  the  higher  level  managers  did  not  differ  greatly.  A 
somewhat  higher  percentage  of  developers  mentioned  providing  management  data, 
improving  access  to  care,  and  improving  coordination  between  departments  than 


TABLE  1 
NOHIMS  Goals 

According  to  NHRC  NOHIMS  Developers  and  Higher  Level  Managers 
(Number  who  mentioned  goal;  multiple  answers  allowed) 


NHRC 

NOHIMS 

Developers 

Higher  Level 
Managers 

TOTAL 

%  of 
Total 

Interviewed 

Improve  medical 
surveillance 

4 

6 

10 

91 

Meet  OSHA 
requirements 

4 

5 

9 

82 

Improve  workplace 
monitoring 

3 

6 

9 

82 

Provide  data  for 

epidemiologic 

analysis 

4 

5 

9 

82 

Provide  management 
data 

4 

4 

8 

73 

Improve  patient 
care 

3 

4 

7 

64 

Improve  resources 
utilization 

3 

4 

7 

64 

Provide  data  for 
legal  functions 

3 

4 

7 

64 

Improve  coordination 
between  departments 

3 

3 

6 

54 

Improve  access 
to  care 

3 

2 

5 

45 

Improve  manpower 

utilization  1  U  s  as 


the  managers.  A  slightly  higher  percentage  of  managers  mentioned  improving 
manpower  utilization  than  did  the  developers. 

Table  2  shows  that  82  percent  of  the  NHRC  NOHIMS  developers/higher  level 
managers  rated  NOHIMS  as  meeting  the  goals  either  very  well  or  somewhat  well. 

In  Table  3  the  three  areas  mentioned  most  often  by  the  NHRC  NOHIMS  developers 
and  higher  level  managers  as  areas  in  which  NOHIMS  is  not  fully  meeting  the 
goals  were  providing  management  data,  improving  medical  surveillance,  and 
providing  data  for  epidemiologic  analysis,  although  in  each  case  only  half  or 
less  of  those  interviewed  mentioned  these  goals  as  not  being  fully  met. 

Everyone  interviewed  thought  NOHIMS  was  helping  to  meet  OSHA  requirements. 

Table  4  contains  a  summary  of  the  comments  that  the  interviewees  made 
explaining  why  they  thought  that  NOHIMS  was  not  meeting  the  system  goals.  The 
main  comments  that  the  NHRC  NOHIMS  developers/higher  level  managers  made  were 
that  they  had  not  seen  enough  output  from  the  system  (55%  of  those  who 
answered),  they  needed  more  training/documentation  for  the  system  (55%),  a 
statistical/analytical  capability  was  required  (55%),  and  that  there  were 
problems  with  the  accuracy/completeness  of  the  database  (44%). 

The  managers  felt  that  they  have  seen  very  little  data  come  out  of  the 
system.  The  lack  of  output  was  reflected  in  the  comment  by  a  manager  that  "we 
are  not  getting  enough  industrial  hygiene  data  back  out  for  what  we  are  putting 
into  the  system."  Another  manager  stated  that  he  would  like  to  see  regular 
monthly  feedback  to  the  users.  One  NOHIMS  developer  stated  that  the  system  had 
not  been  used  enough  yet  to  provide  management  data.  The  criticism  generally 
levied  was  not  that  NOHIMS  could  not  provide  the  appropriate  output,  but  rather 
that  the  system  was  not  being  utilized  properly  to  obtain  the  needed  data.  The 
lack  of  output  contributed  to  the  assessment  that  NOHIMS  fell  short  of  many  of 
the  goals,  especially  the  workplace  monitoring  and  management  data  goals. 

Several  of  the  managers  that  were  interviewed  stated  that  they  or  people 
under  them  had  received  inadequate  training  in  the  use  of  NOHIMS.  They  felt 
that  training  was  required  in  both  an  overview  of  NOHIMS  functions  as  well  as  in 
specific  areas  of  operation.  Developers  expressed  concern  that  adequate 
training  be  provided  to  future  users  to  ensure  the  usefulness  of  the  system. 

They  clearly  felt  that  the  system  could  be  very  powerful  if  users  were  properly 
trained,  but  if  users  were  not  trained  and  there  was  not  enough  user 
involvement,  then  NOHIMS  could  fail  to  achieve  its  goals. 

The  main  criticism  that  developers  and  managers  made  in  regard  to  NOHTMS 
adequately  providing  data  for  epidemiologic  analysis  was  that  NOHIMS  lacked 
statistical  and  analytical  capabilities.  These  capabilities  would  also  be 
useful  in  short-term  investigations  in  the  workplace  monitoring  program. 

Questions  about  the  accuracy  and  completeness  of  the  database  revolved 
around  two  problems.  Several  of  those  interviewed  in  San  Diego  stated  that  the 
Personnel  Extract  File  was  not  up-to-date,  and  therefore,  made  the  personnel 
data  in  NOHIMS  inaccurate.  Also,  two  of  those  interviewed  stated  that  some  of 
the  data  for  the  occupational  health  clinic  examinations  were  inaccurate. 

NOHIMS  showed  that  very  few  respirator  examinations  were  conducted  during  a  6- 
month  period;  however,  the  clinic  personnel  had  done  many  examinations.  We 
looked  into  this  problem  and  found  that  the  data  collection  forms  do  have  a  data 
item  for  the  number  of  respirator  examinations  conducted  at  the  occupational 


TABLE  2 

Rating  of  How  Well  NOHIMS  Is  Meeting  Goals 
by  NHRC  NOHIMS  Developers  and  Higher  Level  Managers 
(Number  who  mentioned  rating) 


NHRC 

NOHIMS 

Developers 

Higher  Level 
Managers 

TOTAL 

%  of 
Total 

Interviewed 

Very  well 

2 

0 

2 

18 

Somewhat  well 

2 

5 

7 

64 

Somewhat  not  well 

0 

1 

1 

9 

Not  well 

0 

1 

1 

9 

TOTAL  INTERVIEWED 


4 


7 


11 


100 


TABLE  3 

Goals  That  NOHIMS  Is  Not  Meeting  Well 
According  to  NHRC  NOHIMS  Developers  and  Higher  Level  Managers 
(Number  who  mentioned  goal;  multiple  answers  allowed) 


NHRC 

NOHIMS 

Developers 

Higher  Level 
Managers 

TOTAL 

%  of 

Total  Who 
Answered 

Provide  management 
data 

1 

3 

4 

44 

Improve  medical 
surveillance 

2 

1 

3 

33 

Provide  data  for 

epidemiologic 

analysis 

1 

2 

3 

33 

Improve  patient 
care 

0 

2 

2 

22 

Improve  manpower 
utilization 

1 

1 

2 

22 

Improve  workplace 
monitoring 

1 

1 

2 

22 

Improve  resources 
utilization 

1 

0 

1 

11 

Improve  coordination 
between  departments 

0 

1 

1 

11 

Improve  access 
to  care 

0 

1 

1 

11 

Provide  data  for 
legal  functions 

0 

i 

1 

11 

Meet  OSHA 
requirements 

0 

0 

0 

0 

No  specific  goals 


22 


TABLE  4 

Criticisms  of  NOHIMS 

by  NHRC  NOHIMS  Developers  and  Higher  Level  Managers 
(Number  who  mentioned  criticism;  multiple  answers  allowed) 


NHRC 

%  of 

NOHIMS 

Higher  Level 

Total  Who 

Developers 

Managers 

TOTAL 

Answered 

Need  more  output 

2 

3 

5 

55 

Need  training/ 
documentation 

2 

3 

5 

55 

Need  statistical/analysis 
capability 

3 

2 

5 

55 

Problems  with  accuracy/ 
completeness  of  database 

1 

3 

4 

44 

Need  more  equipment 

0 

2 

2 

22 

Problems  with  access 

0 

2 

2 

22 

Need  ability  to  retrieve 
historical  data 

2 

0 

2 

22 

Need  more  personnel 

1 

1 

2 

22 

Need  additional  data 

MSDS  information 

0 

2 

2 

22 

Injury/illness 

0 

1 

1 

11 

Safety  data 

1 

0 

1 

11 

Modules/components 
not  implemented 

0 

1 

1 

11 

Need  special 
survey  data  forms 

1 

0 

1 

11 

TOTAL  WHO  ANSWERED 

3 

6 

9 

100 

No  Comment 

1 

1 

2 

TOTAL  INTERVIEWED 


4 


7 


11 


health  clinic.  Clinic  personnel  claimed  to  be  marking  this  item,  but  very  few 
respirator  exams  were  actually  entered  into  the  database.  In  April  1986  we 
checked  back  with  the  two  interviewees  who  mentioned  this  problem  and  found  that 
the  trouble  had  been  resolved.  The  San  Diego  system  manager  set  up  an 
environment  called  "Respirator  Program"  in  the  industrial  component  to  call  in 
individuals  in  the  respirator  program  for  a  physical  examination  and  require  a 
mandatory  Pulmonary  Function  Test.  The  medical  personnel  marked  the  respirator 
box  on  the  data  entry  form  and  tallies  now  appeared  in  the  semi-annual  reports. 

The  remaining  criticisms  of  NOHIMS  were  mentioned  by  only  one  or  two  of 
those  interviewed.  Nevertheless,  they  were  serious  drawbacks  to  the  interviewee 
who  mentioned  them.  Problems  with  access,  mentioned  by  two  industrial  hygiene 
managers,  reflected  their  concern  as  to  whether  there  would  be  adequate  access 
to  NOHIMS  in  terms  of  equipment,  training,  and  24-hour  availability.  There  were 
concerns  about  having  adequate  resources,  namely  personnel  and  equipment,  to  be 
able  to  fully  utilize  all  of  NOHIMS  capabilities.  Two  of  the  developers 
mentioned  that  NOHIMS  needed  a  function  that  would  retrieve  historical 
industrial  hygiene  data.  The  two  industrial  hygiene  managers  felt  that  it  was 
essential  that  the  NOHIMS  hazard  table  contain  all  of  the  data  on  the  Material 
Safety  Data  Sheet  (MSDS)  for  each  hazard.  It  was  also  suggested  that  the  table 

be  augmented  with  additional  hazards  so  that  NOHIMS  would  provide  more  of  a 

reference  for  the  industrial  hygienist.  This  suggestion  was  mentioned  as  one 

way  of  increasing  the  output  from  NOHIMS.  A  medical  manager  felt  that  it  was  a 

great  oversight  that  NOHIMS  was  not  set  up  to  handle  data  from  the 
illness/in jury  side  of  the  occupational  health  unit.  The  special  data 
collection  forms  that  one  developer  mentioned  were  for  collecting  certain 
industrial  hygiene  survey  data,  especially  data  on  noise  and  heat.  The 
reference  to  modules/components  not  implemented  is  because  Bremerton  has  not 
implemented  the  medical  module  and  does  not  have  access  to  personnel  data  yet. 


System  Users  and  Test  Site  Administrators 


Table  5  contains  the  goals  for  NOHIMS  mentioned  by  the  system  users  and 
test  site  administrators.  All  but  one  person  mentioned  the  goals  of  improving 
medical  surveillance  and  improving  workplace  monitoring.  More  than  half  of 
those  interviewed  mentioned  each  of  the  other  goals,  except  improving  access  to 
care  which  was  mentioned  by  46  percent  of  those  interviewed.  The  industrial 
hygienists  made  the  biggest  difference  in  the  number  of  people  mentioning  a 
goal.  One-fifth  or  less  of  the  industrial  hygienists  felt  that  improving 
coordination  between  departments,  improving  manpower  utilization,  improving 
resources  utilization,  improving  patient  care,  and  improving  access  to  care  were 
goals  for  NOHIMS.  This  finding  suggests  that  they,  in  general,  have  a  more 
focused  view  of  the  goals  for  NOHIMS  than  the  medical  users  or  test  site 
administrators. 


Nine  out  of  eleven  (82%)  of  those  who  rated  NOHIMS  on  how  it  was  meeting 
the  goals  felt  that  it  was  meeting  them  very  well  or  somewhat  well  (see 
Table  6).  One  person  each  rated  NOHIMS  on  how  it  was  meeting  the  goals  as 
somewhat  not  well  and  not  well;  both  of  these  individuals  were  medical  users. 

In  Table  7,  we  see  that  almost  all  of  the  mentions  of  goals  that  NOHIMS  was 
not  meeting  were  by  the  medical  users.  The  goal  that  was  mentioned  by  the  most 
people  was  improving  medical  surveillance,  and  five  out  of  six  of  these  mentions 
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TABLE  5 
NOHIMS  Goals 

According  to  Medical  Care  Providers, 

Industrial  Hygienists,  and  Test  Site  Administrators 
(Number  who  mentioned  goal;  multiple  answers  allowed) 

Medical  %  of 

Care  Industrial  Test  Site  Total 

Providers  Hygienists _ Admin . _ TOTAL  Interviewed 


Improve  medical 
surveillance 

6 

4 

2 

12 

92 

Improve  workplace 
monitoring 

6 

4 

2 

12 

92 

Provide  data  for 

epidemiologic 

analysis 

5 

3 

2 

10 

77 

Provide  management 
data 

5 

3 

2 

10 

77 

Provide  data  for 
legal  functions 

4 

3 

2 

9 

69 

Meet  OSHA 
requirements 

4 

2 

2 

8 

62 

Improve  coordination 
between  departments 

5 

0 

2 

7 

54 

Improve  manpower 
utilization 

4 

1 

2 

7 

54 

Improve  resources 
utilization 

5 

0 

2 

7 

54 

Improve  patient 
care 

5 

0 

2 

7 

54 

Improve  access 
to  care 

5 

0 

1 

6 

46 

TOTAL  INTERVIEWED  6 


5 


2 


13  100 


16 


k 


I 


R: 


s. 


V 


Somewhat  not 
well 


i' 


Not  well 


TABLE  6 

Rating  of  How  Well  NOHIMS  Is  Meeting  Goals 
by  Medical  Care  Providers,  Industrial  Hygienists, 
and  Test  Site  Administrators 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 


Industrial 

Hygienists 


Test  Site 
Admin. 


%  of 

Total  Who 
TOTAL  Answered 


Very  well 
Somewhat  well 


2 

2 


1 

0 


5 

4 


46 

36 


0 

0 


0 

0 


9 

9 


TABLE  7 

Goals  That  NOHIMS  Is  Not  Meeting  Well 
According  to  Medical  Care  Providers,  Industrial 
Hygienists,  and  Test  Site  Administrators 
(Number  who  mentioned  goal;  multiple  answers  allowed) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

Test  Site 
Admin. 

TOTAL 

%  of 

Total  Who 
Answered 

Improve  medical 
surveillance 

5 

1 

0 

6 

54 

Improve  workplace 
monitoring 

4 

0 

0 

4 

36 

Provide  data  for 

epidemiologic 

analysis 

3 

0 

1 

4 

36 

Improve  patient 
care 

3 

0 

1 

4 

36 

Improve  coordination 
between  departments 

3 

0 

0 

3 

27 

Improve  resources 
utilization 

2 

0 

0 

2 

18 

Provide  management 
data 

2 

0 

0 

2 

18 

Improve  manpower 
utilization 

2 

0 

0 

2 

18 

Improve  access 
to  care 

2 

0 

0 

2 

18 

Meet  OSH A 
requirements 

2 

0 

0 

2 

18 

Provide  data  for 
legal  functions 

2 

0 

0 

2 

18 

No  specific  goals 

0 

1 

0 

1 

9 

TOTAL  WHO  ANSWERED  6  4  1  11  100 

No  Comment  0  1  12 

TOTAL  INTERVIEWED  6  5  2  13 


18 


were  by  the  medical  users.  Providing  data  for  epidemiologic  analysis,  improving 
patient  care,  and  improving  workplace  monitoring  were  mentioned  next  most  often 
in  frequency. 

Table  8  presents  the  system  users'  and  test  site  administrators'  criticisms 
of  NOHIMS.  A  striking  finding  is  that  82  percent  of  the  users  and 
administrators  questioned  the  accuracy  or  completeness  of  the  database.  The 
criticisms  about  the  accuracy  or  completeness  of  the  database  fall  into  two  main 
categories,  namely,  problems  with  personnel  data  and  problems  with  exposure 
data.  Both  industrial  hygiene  and  medical  users  in  San  Diego  said  that  there 
were  inaccuracies  in  the  personnel  data  file.  These  errors  were  attributed  to 
inaccuracies  in  the  source  database,  the  Personnel  Extract  File  produced  by  the 
NARF.  At  Bremerton,  personnel  data  were  lacking  completely,  as  the  shipyard  had 
not  been  directed  to  participate  in  NOHIMS. 

Every  one  of  the  medical  users  in  San  Diego  who  questioned  the 
accuracy  or  completeness  of  the  database  specifically  questioned  the  exposure 
data.  They  had  concerns  about  whether  NOHIMS  adequately  tracked  workers, 
especially  those  who  move  from  job  site  to  job  site  such  as  those  in  corrosion 
control,  and  whether  other  government-required  examinations  were  being  tracked. 

In  addition,  several  individuals  expressed  concern  over  incomplete  or  old  survey 
data  leading  to  inaccurate  exposure  information.  Other  concerns  about  the 
exposure  data  were  not  related  to  NOHIMS  in  particular,  such  as  questioning  the 
accuracy  of  exposure  measurement  values  or  treating  the  exposure  measurement 
values  as  a  minimum.  But  some  of  the  specific  concerns  expressed  were 
particular  to  NOHIMS  such  as  seeing  noise  measures  that  were  over  the  threshold 
limit  but  no  noise  examination  was  required  by  NOHIMS,  or  no  measurements  for 
substances  known  to  be  in  the  work  environment.  Because  of  their  distrust  of 
the  exposure  data,  the  medical  users  expressed  ambivalent  feelings  about  the 
management  functions  of  NOHIMS.  NOHIMS  makes  their  jobs  easier,  but  they  are 
uncomfortable  with  allowing  NOHIMS  to  make  medical  monitoring  decisions  because 
they  do  not  fully  trust  the  NOHIMS  decision-making  processes  and  the  database. 

In  April  1986  we  checked  back  with  one  of  the  medical  care  providers  (two 
others  who  had  expressed  concern  were  no  longer  with  the  Occupational  Health 
Unit)  to  see  if  these  data  inaccuracies  had  been  remedied.  The  medical  care 
provider  we  talked  with  stated  that  most  of  the  problems  had  been  resolved 
because  the  users  have  become  more  familiar  with  NOHIMS  and  now  know  when  to 
override  its  recommendations  and  because  methods  have  been  developed  within 
NOHIMS  to  cover  former  "gaps,"  such  as  calling  up  workers  in  certain  hazardous 
occupations.  They  are  still  experiencing  some  problems  but  these  are  a  result 
of  inaccurate  personnel  data  or  out-of-date  survey  data  and  are  not  because  of 
inherent  NOHIMS  design  flaws. 

Ten  other  criticisms  were  made  of  NOHIMS,  although  each  was  mentioned  at 
most  twice.  One  medical  care  provider  and  one  industrial  hygienist  felt  that 
more  trai ning/documentation  was  required  to  properly  use  NOHIMS.  Two  of  the 
hygienists  at  North  Island  commented  that  they  had  inadequate  personnel  and, 
therefore,  they  were  behind  on  survey  data  input  to  the  system.  Other  comments 
that  were  made  included  that  NOHIMS  did  not  provide  enough  output,  NOHIMS  needs 
a  statistical  package,  changes  to  medical  data  collection  forms  are  needed,  and 
NOHIMS  needs  to  include  all  data  from  the  Material  Safety  Data  Sheet  and  data  on 
injury/illness  care.  Also,  one  medical  user  stated  that  he  would  like  the  data 
on  the  Individual  Exposure  Examination  Report  to  include  all  exposures  (instead 
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TABLE  8 

Criticisms  of  NOHIMS 

by  Medical  Care  Providers,  Industrial  Hygienists, 
and  Test  Site  Administrators 

(Number  who  mentioned  criticism;  multiple  answers  allowed) 


Medical 

Care 

Providers 


Problems  with  accuracy/ 
completeness  of  database 


Need  training/ 
documentation 


Need  more  personnel 
Need  more  output 


1 

0 

1 


Need  statistical/analysis 
capability 


Problems  with  access 


Industrial 

Hygienists 


Test  Site 
Admin . 


TOTAL 


1 

2 

0 


0 

0 

0 


2 

2 

1 


0 

0 


0 

0 


%  of 

Total  Who 
Answered 


82 


18 

18 

9 


9 

9 


Need  display  of 

historical  data  1 

Modules/components 

not  implemented  0 

Need  changes  to  medical 
data  collection  forms  1 

Need  additional  data 

MSDS  information  0 

Injury/illness  1 

Safety  data  0 

Need  more  equipment  0 


0  0  19 


0  119 


0  0  19 


1  0  19 
0  0  19 
0  0  0  0 

0  0  0  0 


of  just  those  over  the  threshold)  as  well  as  historical  exposures.  Another 
medical  user  requested  access  to  the  industrial  hygiene  component  to  verify 
exposure  data.  The  mentions  of  modules/components  of  NOHIMS  that  have  not  been 
implemented  are  again  because  the  personnel  files  and  the  medical  component  have 
not  yet  been  implemented  at  Bremerton. 


Summary 


Table  9  shows  the  goals  that  NOHIMS  i.j  not  meeting  well  for  all 
interviewees  combined.  For  each  goal,  less  than  half  of  the  users  thought  that 
NOHIMS  was  not  meeting  that  goal,  although  each  goal  was  mentioned  at  least 

twice.  The  goals  that  were  cited  most  frequently  as  not  being  met  well  were 

improving  medical  surveillance  and  providing  data  for  epidemiologic  analysis. 
These  were  mentioned  by  45  percent  and  35  percent  of  all  individuals 
interviewed,  respectively.  The  main  reasons  why  the  interviewees  felt  that 
NOHIMS  was  not  meeting  these  goals  was  because  there  was  distrust  of  the 

personnel  and  exposure  data,  more  output  was  needed,  and  because  the  system 

needed  statistical  capabilities.  In  addition,  the  managers  and  developers 
thought  that  more  training  was  required  to  fully  utilize  the  system.  Three  of 
the  eight  people  in  the  industrial  hygiene  area  requested  that  the  Material 
Safety  Data  Sheet  information  be  included  in  NOHIMS.  Two  of  those  in  the 
medical  area  thought  that  injury/illness  data  were  essential  to  NOHIMS.  Other 
less  frequent  comments  included  needing  more  equipment  and  personnel,  greater 
access  to  the  system,  the  ability  to  retrieve  historical  exposure  data,  the 
inclusion  of  safety  data,  and  the  need  for  special  survey  data  collection  forms. 


Most  of  the  major  problems  stem  from  the  implementation  of  NOHIMS  rather 
than  errors  in  the  design  of  the  system.  The  inaccuracy  of  personnel  data  is 
due  to  inaccuracies  in  the  source  database;  the  distrust  of  the  exposure  data  is 
because  the  survey  data  are  not  up-to-date  owing  to  inadequate  personnel;  and 
some  criticism  is  the  result  of  inadequate  training  in  the  system's  functions 
and  capabilities.  Criticisms  that  are  design-oriented  include  the  need  for 
statistical  capabilities,  retrieval  of  historical  exposure  data,  and 
injury/illness  data.  It  is  not  clear  whether  the  need  for  more  output  is  a 
design  problem  or  if  it  is  because  the  users  lack  experience  with  or  knowledge 
of  the  system's  functions  in  this  area. 


TABLE  9 

Goals  That  NOHIMS  Is  Not  Meeting  Well 
According  to  All  Individuals  Interviewed 
(Number  who  mentioned  goal;  multiple  answers  allowed) 

%  of 

Total  Who 

TOTAL  _ Answered 


Improve  medical 
surveillance 

9 

45 

Provide  data  for 

epidemiologic 

analysis 

7 

35 

Improve  patient 
care 

6 

30 

Provide  management 
data 

6 

30 

Improve  workplace 
monitoring 

6 

30 

Improve  manpower 
utilization 

4 

20 

Improve  coordination 
between  departments 

4 

20 

Improve  resources 
utilization 

3 

15 

Improve  access 
to  care 

3 

15 

Provide  data  for 
legal  functions 

3 

15 

Meet  OSHA 
requirements 

2 

10 

No  specific  goals 

3 

15 

TOTAL  WHO  ANSWERED  20  100 

No  Comment  4 


TOTAL  INTERVIEWED 


24 
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SECTION  III 

EVALUATION  OF  NOHIMS  SYSTEM  DESIGN 


The  NOHIMS  system  design  has  been  evaluated  in  eleven  areas:  an  overall 
description  of  NOHIMS;  software  quality  attributes;  operational  characteristics, 
including  user  friendliness,  data  manipulation  tasks,  and  information  retrieval; 
NOHIMS  security  features;  hardware  and  software  support  requirements;  available 
system  support;  scenario  descriptions  to  maintain  the  system;  organizational 
requirements;  minimum  hardware  requirements;  suitability  of  NOHIMS  to  the 
information  processing  needs  of  the  Navy;  and  assessment  of  system  performance. 
Each  topic  has  been  covered  in  its  own  subsection.  Descriptive  data  for  these 
subsections  were  drawn  from  both  interviews  with  the  Naval  Health  Research 
Center  (NHRC)  NOHIMS  developers  and  from  the  NOHIMS  documentation.  Some 
subsections  include  subjective  assessments  of  various  attributes  of  NOHIMS  by 
each  of  the  user  categories  consisting  of  NHRC  NOHIMS  developers,  higher  level 
Navy  managers,  medical  care  providers,  industrial  hygienists,  data  entry  clerks, 
and  system  managers,  as  appropriate. 


DESCRIPTION  OF  NOHIMS 

The  following  text  on  NOHIMS  describes  the  overall  organization  of  NOHIMS, 
the  software  language  used  and  the  programming  structure,  and  a  description  of 
the  industrial  and  medical  components  of  NOHIMS. 

Overall  Organization  of  NOHIMS 

NOHIMS  is  composed  of  two  subsystems:  an  industrial  component  and  a 
medical  component.  Each  of  the  two  subsystems  can  operate  as  a  stand-alone 
system,  but  in  NOHIMS  they  function  as  an  integrated  system. 

The  NOHIMS  industrial  component  is  designed  as  a  management  tool  to  assess 
the  extent  of  exposure  of  personnel  to  hazardous  substances  and  other  workplace 
stressors  and  to  provide  an  accurate  determination  of  health  care  requirements 
for  each  worker  based  upon  that  assessment.  While  serving  this  purpose,  it  also 
provides  many  other  procedures  and  features  that  aid  industrial  management 
tasks.  The  industrial  component  functions  in  a  manner  that  is  as  close  as 
possible  to  the  "real  world"  operation  of  a  Navy  agency.  With  a  few 
exceptions,  all  of  the  terminology,  configurations,  names,  and  other  descriptive 
attributes  normally  used  by  the  agency  can  be  used  in  the  operation  of  the 
industrial  component. 

The  medical  component  is  a  comprehensive  and  flexible  medical  information 
and  communication  system  that  has  been  adapted  for  Navy  occupational  medicine. 
Using  special  forms  designed  to  collect  medical  record  data,  the  medical 
component  captures,  stores,  displays,  and  prints  relevant,  complete,  and 
standardized  clinical  information  so  that  it  is  immediately  and  perpetually 
accessible.  Further,  the  system  has  the  capability  to  generate  data  for 
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administrative  reports  in  a  timely  manner,  tabulate  population  statistics,  and 
answer  research  queries. 

Software  Language  Used  and  Programming  Structure 

Both  the  industrial  and  medical  components  of  NOHIMS  are  written  in  ANSI 
Standard  MUMPS.  MUMPS  is  an  acronym  for  the  Massachusetts  General  Hospital 
Utility  Multi-Programming  System.  It  is  a  compact,  high-level  interpretive  data 
management  system.  It  was  originally  designed  for  medical  applications,  but  it 
has  since  become  a  general  purpose  language.  It  is  particularly  suited  for 
interactive  applications  that  require  a  large  shared  database  and  the  rapid, 
efficient  manipulation  of  textual  data.  MUMPS  contains  its  own  file  manager  and 
interpreter.  Some  versions  of  MUMPS  contain  an  operating  system  while  others 
run  under  a  general  purpose  operating  system. 

The  system  routines  for  the  industrial  component  of  NOHIMS  were  written  by 
Donald  D.  Beck,  a  consultant  with  R-K  Research  and  System  Design,  Malibu, 
California  and  The  MITRE  Corporation,  McLean,  Virginia  under  contract  to  the 
Naval  Health  Research  Center  (NHRC),  San  Diego,  California.  The  routines  were 
specifically  designed  and  written  for  NOHIMS,  but  they  would  be  useful  in  a 
variety  of  occupational  health  settings.  The  programming  structure  used  is 
modular  programming.  The  file  system  is  characterized  by  hierarchical  direct 
access  B-tree  files.  The  data  files  are  of  variable  length  and  file  space  is 
dynamically  allocated.  The  industrial  component  uses  foreground  processing. 

The  operation  of  the  industrial  component  system  routines  was  verified 
through  pilot  operation  and  routine  operational  use  at  the  Occupational  Health 
and  Preventive  Medicine  Department,  Industrial  Hygiene  Division  of  the  Naval  Air 
Rework  Facility,  North  Island,  San  Diego,  California  and  the  Puget  Sound  Naval 
Shipyard,  Bremerton,  Washington  in  conjunction  with  staff  from  NHRC.  The 
Description  of  Implementation  Process  at  the  Test  Sites  subsection  of  the 
Evaluation  of  Transferability  of  NOHIMS  to  other  Navy  Industrial  Sites  section 
of  this  report  contains  further  detail  on  the  individuals  involved  in  the 
development  of  the  industrial  component  of  NOHIMS.  The  industrial  component 
software  is  currently  being  maintained  by  NHRC.  NHRC  has  plans  to  expand  the 
Query/Report  function  of  the  system  and  to  modify  the  software  to  provide 
alternative  methods  of  producing  personnel  exposure  reports. 

The  medical  component  of  NOHIMS  is  from  COSTAR — the  Computer  STored 
Ambulatory  Record  system.  The  system  routines  for  COSTAR  were  orginally 
developed  by  the  Laboratory  of  Computer  Science  at  Massachusetts  General 
Hospital  and  Harvard  Medical  School  in  collaboration  with  the  Harvard  Community 
Health  Plan.  Funding  for  this  endeavor  was  provided  by  the  National  Center  for 
Health  Services  Research.  In  1975,  the  system  was  rewritten  as  COSTAR  V  in  ANSI 
Standard  MUMPS  with  expanded  capabilities  and  flexibility.  The  COSTAR  Users' 
Group  has  since  overseen  several  updates  of  the  COSTAR  software.  The  medical 
component  of  NOHIMS  is  based  on  COSTAR  V.7.  Application  programming 
modifications  specific  to  NOHIMS  were  made  to  COSTAR  V.7  by  Kathryn  E.  Guidera, 
MSPH,  and  Anton  S.  Roberts  of  R-K  Research  and  System  Design  under  the 
supervision  of  NHRC.  The  programming  structure  for  the  medical  component  could 
be  described  as  mostly  hierarchical  direct  access  B-tree  files  with  a  lew 
pointer  files  that  are  key  indexed  files.  The  files  are  variable  length  files 
and  file  space  is  dynamically  allocated.  The  medical  component  uses 


approximately  ten  percent  foreground  processing  and  90  percent  background 
processing.  All  encounter  data  filing  is  background  processing;  some 
registration  filing  and  system  maintenance  filing  is  done  in  the  foreground. 

The  operation  of  the  system  routines  for  the  medical  component  was  tested 
by  staff  at  NHRC  and  staff  at  the  Occupational  Health  Unit,  North  Island,  San 
Diego,  California  through  pilot  operation  and  routine  operational  use.  Again, 
the  reader  is  referred  to  the  Description  of  Implementation  Process  at  the  Test 
Sites  subsection  of  this  report  for  further  detail  on  individuals  involved  in 
the  development  process  for  the  medical  component  of  NOHIMS.  The  software  is 
presently  being  maintained  by  NHRC.  No  further  software  enhancements  are 
planned;  however,  NHRC  is  currently  modifying  the  COSTAR  directory  to  allow  the 
processing  of  illness  and  injury  care  data.  The  implementation  of  an 
occupational  history  form  and  a  medical  history  form  have  not  been  completed 
yet. 


Description  of  the  Industrial  Component 

The  following  describes  the  main  function  and  features  of  each  module  and 
option  in  the  industrial  component.  The  reports  generated  by  the  industrial 
component,  data  collection  forms,  and  other  sources  of  data  for  the  system  are 
also  described. 


Description  of  Industrial  Component  System  Modules 

There  are  eight  main  operational  modules  in  the  industrial  portion  of 
NOHIMS.  Five  of  these  modules  deal  with  the  general  areas  of  occupational 
health,  namely,  industrial  organization,  workforce  personnel,  workplace 
environments,  survey  information,  and  hazardous  substances  information.  The 
other  three  primary  modules  are  an  ad  hoc  query  function  for  the  retrieval  of 
information  in  a  user-defined  context,  a  system  maintenance  function  that  is 
used  to  control  security  and  system  file  integrity  and  to  perform  any  necessary 
alterations  to  the  contents  of  the  component's  internal  tables  and  data 
directories,  and  a  transaction/message  process  module  that  integrates  personnel 
data  from  Navy  personnel  records  with  NOHIMS.  These  eight  primary  modules  are 
the  first  level  menu  choices  of  the  industrial  component  and  are  named  as 
follows: 

AGENCY  DATA 
PERSONNEL  DATA 
ENVIRONMENT  DATA 
SURVEY  DATA 
HAZARD  DATA 
MAINTENANCE 

TRANSACTION/MESSAGE  PROCESS 
QUERY/REPORT 

Agency  Data  Module.  This  module  deals  exclusively  with  the  organizational 
configuration  of  the  activity  to  be  managed  by  NOHIMS.  The  term  "agency"  is 
used  as  the  generic  term  for  this  activity.  NOHIMS  must  have  a  complete 
description  of  the  agency  in  order  to  properly  relate  and  manage  personnel  and 
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workplace  environment  data  in  a  "real  world"  context.  The  Agency  Data  module 
contains  three  options  as  follows: 

ORGANIZATION  DEFINITION 
EDIT  ORGANIZATION 
DISPLAY  ORGANIZATION 

These  options  provide  all  of  the  transactional  facility  necessary  to 
completely  define,  alter,  and  display  the  organization  of  an  agency  of  any  size 
or  configuration.  The  agency  configuration  may  range  from  a  single 
organizational  unit  located  at  one  physical  site  to  an  activity  of  practically 
any  organizational  complexity  having  a  multitude  of  geographically  located 
facilities.  The  system  will  accept  nearly  any  form  of  terminology  that  is  in 
use  to  describe  the  geographical  and  organizational  attributes  of  the  agency. 

Organization  Definition.  The  Organization  Definition  option 
allows  definition  of  organizational  components  of  the  agency  called 
units.  The  system  permits  each  unit  to  have  both  a  full  name  (which 
can  be  the  actual  name)  and  a  code  (which  can  be  a  number,  acronym,  or 
abbreviated  name).  The  code  can  be  any  actual  identification 
convention  in  use  as  long  as  it  uniquely  identifies  that  agency  unit. 

This  code  is  usually  the  primary  identifying  term  used  for  agency  unit 
look-up  purposes  throughout  the  industrial  component.  A  unit  name  may 
also  be  looked  up  instead  of  the  code,  however.  All  of  the  agency 
units  are  associated  with  their  actual  hierarchical  level  titles,  such 
as  department,  shop,  etc.  They  are  also  associated  with  their 
geographical  locations,  which  are  generically  called  "sites"  in  the 
system.  The  applicable  industrial  sites  (there  can  be  any  number)  are 
defined  using  the  Maintenance  module  of  the  industrial  component. 

Edit  Organization.  Edit  Organization  allows  all  aspects  of  the 
current  organizational  definition  to  be  altered.  Suboptions  allow  the 
user  to  edit  the  agency's  name,  acronym,  generic  title,  industry  type, 
primary  site,  or  secondary  sites;  add  level(s)  to  the  organization; 
edit  level  title(s);  or  edit  characteristics  of  each  agency  level. 

Display  Organization.  Using  this  option,  the  user  may  display 
all  or  any  portion  of  the  agency  organization.  The  display  is 
organized  so  that  the  hierarchical  configuration  of  the  unit  is 
portrayed.  The  normal  display  for  each  agency  unit  includes  the 
unit's  name,  code,  site  location,  and  the  number  of  environments 
attached  to  it.  Also,  additional  information  such  as  personnel  and 
workplace  environments  applicable  to  each  agency  unit  may  be  included 
in  the  display  output.  If  this  latter  option  is  selected,  a  complete 
description  of  each  environment  is  displayed,  along  with  the  names, 
employee  identification  numbers,  and  the  dates  that  the  persons  were 
assigned  to  the  particular  agency  unit. 

Personnel  Data  Module.  This  module  contains  the  functions  necessary  to 
manage  the  general  employee  workforce  and  other  individuals  as  may  be  associated 
with  the  agency.  This  includes  introducing  new  personnel,  terminating 
personnel,  and  transferring  personnel  within  the  agency.  The  module  contains 
the  following  options: 


PERSONNEL  DATA  ENTRY 

WORKPLACE  ASSIGNMENT/TERMINATION 

HAZARD  EXPOSURE/EXAMINATION  REPORT 

TRAINING  HISTORY 

SAFETY  EQUIPMENT 

EDIT  PERSONNEL  DATA 

DISPLAY  PERSONNEL  DATA 

Personnel  Data  Entry.  Personnel  Data  Entry  provides  the 
capabilities  required  to  introduce  new  employees  into  the  system  and 
to  assign  them  to  their  initial  agency  unit.  The  system  accepts  the 
worker's  name,  sex,  date  of  birth,  social  security  number,  employee 
number  (in  accordance  with  local  conventions),  and  occupation  code. 

If  an  employee  has  been  terminated,  this  option  may  also  be  used  to 
reinstate  the  worker. 

Workplace  Assignment  and  Termination.  This  option  allows 
employees  to  be  independently  associated  with  both  an  agency  unit  and 
as  many  work  environments  as  are  applicable.  For  each  environment 
that  is  assigned,  the  user  may  specify  the  number  of  hours  per  week 
that  the  person  is  usually  present  in  the  environment.  The  worker  may 
also  be  disassociated  from  a  work  environment(s) ,  transferred  from  one 
agency  unit  to  another,  terminated  from  active  status,  or  the 
proportion  of  time  a  person  spends  in  each  of  the  assigned 
environments  may  be  edited. 

Hazard  Exposure/Examination  Report.  The  Hazard  Exposure/ 
Examination  Report  option  produces  the  hazard  exposure  summary  and 
medical  examination  requirement  reports  (Individual  Exposure 
Examination  Reports)  for  the  workers  that  are  selected.  In  addition, 
the  Occupational  Health  Roster  (a  roster  listing  employees  who  require 
medical  examinations  within  each  applicable  agency  unit)  and  a 
Physical  Exam  Notification  Report  (a  medical  examination  notice)  for 
each  employee  in  the  Occupational  Health  Roster  may  also  be  produced. 

There  are  a  variety  of  ways  to  select  individuals  for  generating 
reports.  Usually  the  Periodic  Exam  Preparation  suboption  is  used  to 
select  all  personnel  within  the  agency  who  were  born  in  a  specified 
month  and  need  an  annual  physical  examination.  NOHIMS  will  select  a 
worker  for  a  physical  examination  only  if  the  environments  associated 
with  the  worker  contain  an  agent  with  mandatory  medical  requirements 
or  if  a  measured  hazardous  agent  concentration  value  of  an  agent  in 
the  worker's  environment(s)  has  exceeded  the  applicable  medical  action 
level  limits.  The  reports  can  be  produced  using  criteria  for 
preplacement  examinations,  termination  examinations,  or  normal 
periodic  examinations.  The  user  may  also  select  specific  individuals 
or  all  of  the  employees  of  a  specific  agency  unit  by  using  the  Special 
Examination  Preparation  suboption.  This  suboption  also  produces  a 
general  exposure  and  examination  report  for  environments  rather  than 
personnel.  All  reports  will  list  all  pertinent  hazardous  agents, 
concentration  sample  values,  and  associated  medical  requirements. 

Once  a  particular  report  has  been  generated,  multiple  copies  of 
the  report  may  be  printed.  The  printing  of  a  report  may  also  be 
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restarted  at  a  failure  point  or  at  the  beginning  of  the  report  using 
the  Restart  a  Prepared  Report  suboption.  The  Occupational  Health 
Roster  and  Physical  Examination  Reports  can  also  be  printed  any  number 
of  times.  The  Delete  Old  Reports  suboption  is  used  to  erase  sets  of 
report  specifications  stored  in  the  system. 

Training  History.  This  option  was  intended  to  allow  the  user  to 
keep  track  of  all  formal  training  classes  the  employee  has  completed. 
Classes  about  hazardous  substances,  equipment  use,  first-aid,  and 
other  emergency  procedures  would  be  included.  When  utilizing  this 
option,  data  such  as  title  of  class  and  date  of  completion  of  the 
class  would  become  a  permanent  part  of  the  employee's  personnel 
record.  Although  Training  History  is  included  in  the  option  menu,  it 
was  not  implemented  in  Version  1.0  of  NOHIMS. 

Safety  Equipment.  The  Safety  Equipment  option  was  intended  to  be 
used  to  enter  and  retrieve  information  about  safety  equipment  (e.g., 
earplugs,  safety  shoes,  safety  glasses,  and  respirators)  issued  to  an 
employee.  The  make,  model,  and  serial  number  of  the  equipment  issued, 
along  with  the  date  of  issue  and  date  of  return,  would  be  stored  for 
each  piece  of  equipment  issued.  Again,  it  was  not  implemented  in 
Version  1.0  of  NOHIMS. 

Edit  Personnel  Data.  Using  this  option,  the  user  may  alter  any 
portion  of  the  employee's  personnel  record  in  NOHIMS.  Suboptions 
differentiate  between  edit  (correction)  operations  and  update 
operations  on  the  worker's  name.  Editing  of  the  name  replaces  the 
previous  worker  name.  Updating  the  name  causes  an  historical  audit 
trail  to  the  previous  name,  allowing  the  system  to  recognize  the 
worker  by  both  the  old  and  new  name.  The  social  security  number, 
employee  number,  sex,  and  date  of  birth  may  also  be  edited  with  this 
function. 

Display  Personnel  Data.  This  function  allows  a  user  to  display 
the  personnel  data  for  a  selected  worker  or  all  workers  for  a  selected 
agency  unit.  The  display  that  is  produced  includes  personnel 
demographic  data,  the  current  agency  unit  to  which  the  worker  is 
assigned,  the  date  the  worker  was  assigned  to  that  unit,  and 
information  for  the  worker's  currently  assigned  work  environment.  The 
user  may  also  opt  to  include  the  medical  examination  information  in 
the  display.  The  medical  examination  information  includes  current 
medical  examination  recommendations,  examination  status,  and  hazardous 
agent  exposure  information. 

Environment  Data  Module.  The  functions  of  the  Environment  Data  module 
allow  a  user  to  compile  a  list  of  environments  contained  in  the  agency.  In 
NOHIMS,  an  environment  may  be  one  of  three  distinct  types:  a  physical 
workplace;  an  occupational  category;  or  a  circumstance,  event,  or  other 
situation  that  is  descriptive  of  the  location  or  conditions  affecting  working 
personnel  such  as  an  industrial  accident.  The  Environment  Data  module  contains 
options  that  allow  the  user  to  create  environments  and  then  to  assign  the 
environment  to  applicable  agency  units.  Environment  Data  has  five  options  that 
are  accessed  through  the  module's  primary  option  menu: 


CREATE  ENVIRONMENTS 
DISPLAY  ENVIRONMENT  USERS 
REVIEW  ENVIRONMENT  INFORMATION 
EDIT  ENVIRONMENT  DATA 

ASSIGN  ENVIRONMENT  TO  ORGANIZATIONAL  UNITS 

Create  Environments.  Create  Environments  is  used  to  initially 
define  any  type  of  environment.  The  user  is  simple  asked  to  specify 
the  environment  type  and  furnish  the  environment  name.  Building  and 
room  numbers,  areas,  incident  names,  or  other  textual  terms  of  user 
choice  may  be  used  to  describe  the  environment.  Since  certain 
environments  cannot  be  surveyed,  such  as  occupational  categories,  this 
option  allows  a  user  to  specify  a  set  of  mandatory  medical 
requirements  for  an  environment.  These  requirements  will  then  always 
be  applied  to  all  personnel  associated  with  the  environment  in 
exposure  reporting  functions.  Such  requirements  are  used  to 
supplement  the  exposure  data  that  are  normally  derived  from  survey 
information . 

Display  Environment  Users,  Review  Environment  Information.  The 
Display  Environment  Users  option  is  used  to  quickly  retrieve  and  list 
environment  descriptions  and  the  associated  agency  units.  No  other 
information  is  provided  in  the  display.  The  user  may  select  any 
agency  unit  environment(s)  for  display.  The  environment(s)  for 
display  may  be  selected  by  their  association  with  agency  units  or  by 
keyword  content  of  their  description  (such  as  "spill").  The  Review 
Environment  Information  option  will  retrieve  environments  in  the  same 
manner  as  the  Display  Environment  Users.  However,  the  user  may  also 
display  any  one  or  combination  of  the  following:  environment 
description,  organizational  users,  personnel  assigned  to  the 
environment,  mandatory  medical  requirements,  survey  references,  or 
material  inventory. 

Edit  Environment  Data.  This  option  allows  alteration  of  the 
environment  description  and  user-specified  medical  requirements,  if 
any  have  been  defined.  The  previous  environment  description  is 
archived  in  the  system  along  with  the  date  of  the  edit  or  update. 

Assign  Environment  to  Organizational  Units.  The  Assign 
Environment  to  Organizational  Units  option  is  used  to  associate  or 
disassociate  an  environment  with  the  organizational  units  within  the 
agency  that  have  personnel  who  may  be  working  in  the  environment.  An 
environment  may  be  associated  with  any  number  of  organizational  units. 

If  an  environment  is  de-assigned  from  an  agency  unit,  all  personnel 
within  that  agency  unit  who  are  currently  associated  with  the 
environment  will  be  de-assigned. 

Survey  Data  Module.  The  Survey  Data  module  is  used  to  enter,  edit,  and 
display  data  from  the  surveys  of  the  industrial  hygienists.  The  term  survey 
denotes  the  industrial  hygienist's  collection  of  observed  and  measured 
information  concerning  the  contents  and  conditions  of  an  environment.  Data  for 
a  survey  are  collected  using  three  forms.  The  Industrial  Hygienist  Survey  (1IIS) 
is  used  to  collect  facts  and  conditions  about  the  general  workplace.  The 
Occupational  Hazard  Data  Sheet  (OHDS)  is  used  for  gathering  material  sampling 
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and  exposure  data  and  is  prepared  for  each  hazardous  agent  sampled  in  an 
environment.  The  Material  Inventory  (MI)  is  used  to  record  the  presence  of  each 
agent,  material,  or  product  found  in  the  environment.  The  following  options  are 
available  under  the  Survey  Data  module: 

CREATE  SURVEY 
EDIT  SURVEY  DATA 
DISPLAY  SURVEY  DATA 

Create  Survey.  The  Create  Survey  option  is  used  to  enter  the 
survey  data  collected  with  the  IHS,  OHDS,  and  MI  forms.  NOHIMS  allows 
local  conventions  to  be  used  to  identify  each  set  of  survey  data  as 
long  as  the  terms  used  uniquely  identify  the  survey.  Data  are  entered 
via  a  series  of  system  prompts.  The  contents  and  order  of  the  prompt 
sequence  is  set  by  the  system  manager  using  the  Maintenance  module. 

To  enter  a  survey,  the  data  entry  clerk  first  enters  the  data  from  the 
IHS  form.  Once  these  data  have  been  entered,  the  data  entry  clerk 
selects  suboptions  that  drive  the  prompt  sequence  for  the  OHDS  or  the 
MI.  One  set  of  OHDS  data  is  entered  for  each  agent  that  was  sampled 
in  the  environment  or  for  each  different  set  of  concentration 
measurements  for  the  same  hazardous  agent.  The  data  entry  clerk  may 
enter  as  many  OHDSs  as  are  required  to  describe  the  environment. 

Edit  Survey  Data.  The  data  that  are  first  entered  for  an 
environment  are  used  as  a  base-line  survey.  Whenever  new  data  are 
gathered  or  changes  are  observed  in  subsequent  surveys  of  the  same 
environment,  the  Edit  Survey  Data  option  is  used  to  alter  the  base¬ 
line  survey  and  to  keep  the  survey  information  up-to-date.  Sample  and 
measurement  data  for  agents  are  kept  historically.  Edit  Survey  Data 
contains  selection  options  for  the  IHS,  OHDS,  and  MI,  so  data  from  any 
of  these  three  forms  may  be  edited  with  this  option.  Survey  data  that 
are  obsolete  may  also  be  deleted  with  this  option. 

Display  Survey  Data.  The  Display  Survey  Data  option  will  display 
a  selected  survey,  or  any  or  all  surveys  associated  with  the  agency 
unit(s)  or  envi  onment(s)  selected  for  display.  The  environment(s) 
may  be  selected  by  their  association  with  agency  units  or  by  keyword 
content  of  their  description.  The  user  may  select  to  include  data 
from  any  or  all  of  the  survey  data  forms.  The  Industrial  Hygienist 
Survey  form  display  retrieves  general  workplace  facts  and  conditions; 
the  Occupational  Hazard  Data  Sheet  display  contains  material  sampling 
and  exposure  data;  and  the  Material  Inventory  display  is  a  list  of  the 
agents,  materials,  or  products  found  in  the  environment(s)  associated 
with  the  survey. 


Hazard  Data 
materials,  condi 
are  found  in  the 
information  pert 
medical  exposure 
For  example,  the 
Exposure  Levels 
codes.  The  data 
reflect  commonly 


Module .  NOHIMS  has  a  table  that  contains  all  chemical  agents, 
tions,  and  other  physical  phenomena  and  their  attributes  that 
work  environments.  The  table  is  an  extensive  collection  of 
inent  to  the  identification,  industrial  control,  sampling,  and 
effects  and  examination  requirements  for  each  of  the  hazards, 
table  includes  Threshold  Limit  Values  (TLVs),  Permissible 
(PELs),  NIOSH  and  Navy  exposure  limits,  agent  synonyms,  and  CAS 
contained  in  the  table  are  derived  from  many  sources  and 
used  standards  and  other  attributes.  Some  of  the  information 
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for  certain  agents  is  not  included  in  the  system  because  the  data  are  unknown, 
data  have  not  been  established  by  an  authoritative  body,  or  because  there  are 
conflicting  opinions  on  certain  attributes  of  the  agents.  The  Hazard  Data 
module  creates  and  maintains  the  data  in  the  table.  It  allows  each  local  site 
to  review,  alter,  and  add  to  the  table  so  that  it  will  agree  with  local 
standards,  practices,  and  procedures.  The  following  options  are  available  under 
Hazard  Data: 

EDIT  HAZARD  DATA 
HAZARD  DATA  ENTRY 
DISPLAY  HAZARD  DATA 

Edit  Hazard  Data.  The  attributes  of  an  agent  in  the  table  may  be 
edited  and  kept  up-to-date  with  the  Edit  Hazard  Data  option.  The  date 
of  the  update  is  also  stored  as  part  of  the  record. 

Hazard  Data  Entry.  New  agents  may  be  added  to  the  table  with 
this  option.  For  each  new  agent,  NOHIMS  solicits  the  agent  primary 
and  synonymous  names;  code  numbers;  medical  monitoring  status; 
classification  category ( ies) ;  analytical  method  number;  sampling  and 
analytical  error;  exposure  limits  including  scale,  authority,  and 
various  limits;  body  parts  and  organ  systems  affected;  medical 
surveillance;  and  protocol  for  the  recommended  procedures  used  to 
monitor  for  effects  of  the  agent. 

Display  Hazard  Data.  All  current  information  contained  in  the 
Hazard  Table  for  a  selected  agent(s)  may  be  displayed  via  this  option. 

The  user  may  also  select  to  include  in  the  display  those  environments 
that  contain  the  selected  agent  using  the  Locations  suboption. 

The  ease  of  identification  and  retrieval  of  agents  is  an 
important  characteristic  of  the  NOHIMS  design.  It  is  practically 
impossible  for  a  user  to  remember  the  exact  spelling  and  other 
distinguishing  attributes  of  the  hundreds  of  agents  and  compounds 
contained  in  the  hazardous  agent  table.  Also,  most  agents  have  many 
synonyms,  as  well  as  a  primary  name.  Therefore,  NOHIMS  allows  any 
number  of  synonyms  to  be  associated  with  an  agent  for  identification 
purposes.  An  agent  can  be  identified  by  either  one  of  two  NOHIMS 
codes  or  a  partial  entry  of  the  agent  name.  The  system  then  returns  a 
candidate  list  containing  agents  whose  names  contain  the  partial  entry 
and  the  user  selects  the  desired  agent. 

Maintenance  Module.  The  Maintenance  module  is  used  to  both  initialize  and 
maintain  the  system.  During  initialization ,  the  agency  that  NOHIMS  is  to  serve, 
required  system  table  data,  information  concerning  the  hardware  configuration, 
and  control  information  for  each  system  user  are  defined.  Most  of  these  data 
items  require  periodic  inspection,  additions,  changes,  or  deletions  to  keep  the 
information  consistent  with  current  operating  needs  and  up-to-date  with  latest 
information.  Via  the  following  options,  the  NOHIMS  system  manager  defines 
initial  parameters,  controls  security,  maintains  system  file  integrity,  and 
performs  any  necessary  alteration  to  the  industrial  component's  internal  tables 
and  data  directories. 


AGENCY/SITE  DEVICE  DEFAULTS 

SECURITY  FUNCTIONS 

INTEGRITY  CHECK  &  CRASH  RECOVERY 

SYSTEM  TABLE  EDIT 

DEVICE  DEFINITION/EDIT 

ERROR  REPORT 

DEFINE  AGENCIES/SITES 

DIRECTORY  MAINTENANCE 

GENERAL  REPORTS 

Agency/Site  Device  Defaults.  This  option  is  used  to  temporarily 
alter  the  default  agency  and  site  values  for  a  specific  device  for  a 
specific  work  session.  It  is  useful  only  when  a  single  industrial 
component  is  operating  with  multiple  agencies  rather  than  a  single 
agency.  It  allows  the  system  manager  to  work  in  any  agency  during  a 
session  without  making  a  permanent  change  to  the  agency  and  site 
defaults  that  happen  to  be  assigned  to  the  particular  device  in  use. 

Security  Functions.  Each  user  of  the  industrial  component  must 
be  assigned  a  three  to  five  character  identification  code.  This  is 
the  ID  Code  used  to  gain  access  to  NOHIMS  during  the  log-on  procedure. 
Using  this  option,  a  list  of  system  modules  and  options  that  the  user 
is  allowed  to  access  is  defined  and  edited.  A  similar  sort  of  options 
list  is  also  associated  with  each  terminal  device.  A  user  is  then 
allowed  access  to  only  those  options  that  are  on  both  his/her  option 
list  and  the  option  list  for  the  device  in  use.  The  Security 
Functions  option  is  also  used  to  define,  edit,  or  delete  "domains" 
that  may  be  associated  with  users.  The  domains  are  used  as  an  address 
for  report  or  message  transmittal  within  the  system.  A  domain 
includes  an  agency  and  the  person  within  the  agency  to  be  targeted. 

Integrity  Check  &  Crash  Recovery.  If  a  "hard"  computer  crash 
occurs  during  a  filing  operation,  it  is  likely  to  cause  corruption  of 
the  global  files.  The  integrity  check  operations  search  the  filed 
configuration  of  the  global  files  and  record  any  erroneous  filing 
conditions  that  are  found.  Usually,  the  condition  can  be  corrected 
through  execution  of  an  automatic  correction  process  which  is  capable 
of  interpreting  the  error  records  that  were  recorded  by  the  integrity 
checking  routines  and  perform  the  necessary  corrections  to  the  files. 
The  integrity  check  routines  are  run  on  a  hardcopy  device  in  order  to 
obtain  descriptions  of  errors  that  are  found. 

System  Table  Edit.  This  option  allows  editing  of  all  industrial 
component  tables.  These  tables  are,  for  the  most  part,  translation 
tables  used  to  encode  and  decode  data.  The  tables  and  their  mnemonic 
identifiers  are  as  follows: 

HIS:  Medical  history  examination  code  to  text 

LAB:  Medical  laboratory  examination  code  to  text 

PEX:  Medical  physical  examination  code  to  text 

SAM:  Sample  media  code  to  text 

CON:  List  of  concentration  scales  and  units 

FLG:  Medical  examination  applicability  flag  codes 

OCC:  Occupation  code  to  text 


PPR:  Physical  restrictions  code  to  text 
BOD:  Body  part  and  organ  systems  code  to  text 
MED:  Mandatory  medical  requirements  (Medical  Program  codes 
and  associated  examination  and  flag  sets) 

QES:  Question  "?"  entry  response  table 

The  System  Table  Edit  option  also  allows  access  to  the  device  and 
user  option  tables  via  separate  suboptions.  The  Users  suboption  calls 
the  Security  Functions  main  menu,  and  a  Devices  suboption  invokes  the 
Device  Definition/Edit  option.  A  Response-to-?  suboption  invokes  an 
editor  routine  for  the  user  question  response  table.  The  other  system 
tables  are  accessed  via  a  Tables  suboption. 

Device  Definition/Edit.  This  suboption  allows  definition  and 
editing  of  the  parameters  for  each  hardware  input/output  device  to  the 
industrial  component.  The  system  must  have  each  device  defined  in  an 
internal  table  because  many  items  of  information  concerning  the 
specific  device  are  required  for  the  correct  performance  of  tasks 
throughout  the  system.  This  option  defines  various  control 
characters,  default  agency  and  site,  the  location  of  the  device,  and 
various  display  parameters.  Each  device  is  defined  during  system 
initialization;  however,  any  change  of  device  ports,  device  additions, 
or  device  deletions  will  require  alteration  of  the  internal  device 
table  via  this  option. 

Error  Report.  This  option  is  used  as  a  monitor  and  aid  to 
identification  of  system  routine  or  file  malfunction.  The  industrial 
component  has  the  capability  of  intercepting  operational  error 
interrupts  during  routine  execution.  Such  an  interrupt  aborts  the 
ongoing  task  when  the  error  is  detected  and  logs  the  error  and 
associated  memory  contents  in  an  error  file  so  that  it  can  be  reviewed 
via  this  option  by  system  programmers.  Old  or  corrected  error  reports 
can  be  deleted  by  using  a  Kill  suboption. 

Define  Agencies/Sites.  This  option  allows  definition  of  any 
number  of  industrial  sites  using  both  a  full  name  and  a  short  acronym 
for  site  identification.  The  sites  describe  the  geographical  or 
physical  locations  of  facilities  associated  with  the  agency.  Since  it 
is  possible  for  agency  units  to  have  the  same  name  and/or  code  yet  be 
located  at  different  geographical  sites,  the  only  way  to  uniquely 
identify  these  agency  units  is  to  include  site  locations  in  their 
identification.  Site  names  and  acronyms  may  also  be  edited  with  this 
option . 

Directory  Maintenance.  This  option  allows  the  system  manager  to 
add  codes  to  the  directories,  edit  parameters  for  existing  codes, 
review  parameters  for  specified  codes,  or  to  display  all  or  part  of 
the  directories.  It  also  has  suboplions  for  editing  filing  control, 
input  control,  creating  an  alphabetic  directory  for  look-up  by  names, 
forms  edit/display,  subdirectory  member  edit,  and  division  edit. 

General  Reports.  This  option  accesses  a  general  report  selection 
menu.  The  menu  provides  a  place  to  link  any  new  reports  written  for 
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the  industrial  component.  Selection  of  an  option  under  General 
Reports  causes  the  specified  report  to  be  executed. 


Transaction/Message  Process  Module.  This  module  provides  NOHIMS  with  the 
functions  to  process  personnel  transactions  from  an  outside  personnel  file.  It 
was  also  intended  to  be  used  to  transmit  to  and  receive  messages  and/or  reports 
from  users  via  the  system.  The  module  has  the  following  three  options: 

RECEIVED  MESSAGE  PROCESSING 
TRANSMIT  MESSAGE  PREPARATION 
PERSONNEL  TRANSACTION  PROCESSING 

Received  Message  Processing.  This  option  was  not  implemented  in 
Version  1.0  of  NOHIMS.  The  intention  was  that  it  would  be  used  to 
read/receive  any  reports  or  messages  that  were  transmitted  through  the 
system. 

Transmit  Message  Processing.  This  option  was  intended  to  be  used 
for  creating  a  message  for  another  system  user  or  to  send  an 
industrial  component  report,  such  as  a  personnel  file,  to  another 
user.  It  was  not  implemented  in  NOHIMS  Version  1.0. 

Personnel  Transaction  Processing.  The  Personnel  Transaction 
Processing  option  is  used  to  process  external  personnel  data  and  store 
it  in  the  NOHIMS  database.  This  option  has  four  suboptions: 

PROCESS  AN  EXTERNAL  TRANSACTION  FILE 
PROCESS  AN  INTERNAL  TRANSACTION  FILE 
MANUAL  ERROR  CORRECTION  AND  PROCESSING 
DELETE  AN  INTERNAL  TRANSACTION  FILE 

Process  An  External  Transaction  File.  This  suboption  is 
used  on  a  monthly  basis  to  update  the  NOHIMS  personnel  records 
from  the  agency's  personnel  files.  The  agency  personnel  file, 
called  an  "external"  transaction  file,  is  processed  by  this 
suboption  to  produce  an  "internal"  personnel  transaction  file. 

The  external  file  may  be  introduced  to  NOHIMS  via  three 
different  methods:  Tape  input,  DMC  network  transmission  input, 
or  ASYNCHRONOUS  terminal  device  input.  A  copy  of  the  most 
recent  transmission  file  is  stored  internally,  labeled  with  the 
processing  month.  The  current  transmission  file  is  compared  to 
the  previously  stored  one  to  determine  the  personnel 
transactions  that  occurred  during  the  intervening  time  period. 

Process  An  Internal  Transaction  File.  The  Process  An 
Internal  Transaction  File  suboption  automatically  processes  and 
updates  the  NOHIMS  personnel  data  files.  It  is  automatic  in 
that  when  an  error  is  detected  in  a  personnel  file,  an  error 
message  is  displayed  and  the  record  is  flagged  as  an  error 
record  and  is  not  processed.  If  records  are  flagged  as  in 
error,  the  Manual  Error  Correction  and  Processing  suboption  must 
be  run  in  order  to  correct  the  errors.  If  the  sex  of  a  newly 
hired  worker  is  missing  from  the  personnel  record  during 
automatic  processing,  NOHIMS  will  prompt  for  the  sex.  The 


system  will  display  the  employee  number  and  name  to  assist  the 
user  in  determining  the  worker's  sex.  NOHIMS  must  know  the 
worker's  sex  to  enter  him/her  into  the  database. 

Manual  Error  Correction  and  Processing.  This  suboption 
processes  the  internal  transaction  file,  but  allows  interactive 
correction  of  errors  at  the  time  they  are  found.  If  the  user 
can  provide  correct  data,  the  record  will  be  processed  as 
normal.  If  not,  it  will  be  flagged  as  an  error  record.  The 
errored  record  may  be  corrected  at  a  later  date  by  re-running 
the  Manual  Error  Correction  and  Processing  suboption  or  by  using 
the  Edit  Personnel  Data  option  in  the  Personnel  Data  module.  If 
the  Manual  Error  Correction  and  Processing  suboption  is  run  on 
an  internal  transaction  file  that  has  already  been  processed  by 
the  Process  An  Internal  Transaction  File  suboption,  only  those 
records  that  were  flagged  as  in  error  will  be  processed. 

Delete  An  Internal  Transaction  File.  When  the  user  is 
satisfied  that  all  of  the  transactions  in  an  internal 
transaction  file  have  been  processed  into  the  database  properly, 
the  internal  file  is  deleted  with  this  suboption. 

Query/Report  Module.  The  Query/Report  module  provides  an  ad  hoc 
information  retrieval  and  display  capability  that  extends  to  almost  every  data 
item  in  the  industrial  component  of  NOHIMS.  This  module  contains  the  following 
options: 

CREATE  A  NEW  QUERY 
DISPLAY  A  QUERY  FILE 
ERASE  A  QUERY  FILE 
TEST  OR  RUN  A  QUERY 

Create  a  New  Query.  To  generate  a  query,  the  user  first  defines 
a  "command  set"  using  the  Create  a  New  Query  File  option.  The  command 
set  contains  the  user's  selections  from  a  menu  progression.  The 
presentation  of  the  data  selection  menus  follows  a  logical  progression 
through  the  various  industrial  component  data  groups.  The  menu  at  any 
point  in  the  selection  process  allows  selection  of  only  those  data 
groups  that  are  possible  given  the  previous  data  group  selections  and 
the  interrelationships  of  those  data  groups  with  other  data  groups  in 
the  component.  The  command  set  specifies  only  general  data  groups  and 
data  items,  the  sequence  of  information  retrieved,  and  the  user's 
desire  to  specify  target  subjects  within  each  data  group.  It  does  not 
identify  individual  target  subjects.  The  selection  of  individual 
target  subjects  within  the  data  group  is  accomplished  interactively 
during  the  initial  portion  of  the  query  execution  process.  Therefore, 
the  same  command  set  may  be  used  to  retrieve  unlimited  combinations  of 
specific  target  data  accessible  by  the  sequence  of  the  general  query 
command  set.  When  a  set  of  individual  data  items  is  selected  for  the 
query,  the  user  can  select  any  or  all  of  the  data  items  in  the  group 
for  retrieval.  Conditional  testing  of  a  data  item  is  planned  as  a 
future  enhancement.  Possible  testing  conditions  for  the  industrial 
component  will  include  comparison  to  a  given  numeric  value,  comparison 
to  a  given  numeric  interval,  testing  for  the  presence  or  absence  of  a 
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data  item,  comparison  to  a  given  literal  value,  a  search  of  the  data 
item  content  for  a  given  single-  or  multi-word  literal,  and  comparison 
to  an  associated  table  of  values  if  applicable  to  the  data  item. 

There  is  no  capability  to  edit  command  sets.  A  command  set  is  so 
easily  built,  that  it  is  simpler  to  create  a  new  command  set  than  to 
modify  an  existing  one. 

Display  a  Query  File.  The  query  command  sets  may  be  displayed 
for  review  using  the  Display  a  Query  File  option. 

Erase  a  Query  File.  A  command  set  is  stored  in  the  system  under 
a  user  selected  name  until  the  command  set  is  deleted  with  the  Erase  a 
Query  File  option. 

Test  or  Run  a  Query.  To  run  a  query  set,  the  user  selects  a 
query  command  set  and  runs  it.  If  the  user  indicated  a  desire  to 
select  specific  target  subjects  of  each  data  group,  the  system  will 
prompt  for  the  target  subject  during  the  initial  portion  of  the  query 
execution  process.  A  run  interprets  the  command  set  and  displays  the 
desired  information.  The  output  display  format  of  the  retrieved  data 
is  not  under  control  of  the  user.  The  query  performs  a  simple 
progressive  indentation  of  the  information  for  each  unique  data  group, 
much  like  an  outline.  The  absence  of  format  control  makes  the 
interactive  query  a  simple  and  quick  way  to  retrieve  data. 


Description  of  Industrial  Component  Data  Collection  Forms 

The  industrial  component  of  NOHIMS  uses  three  data  collection  forms  to 
collect  industrial  hygiene  survey  data.  These  are  the  Industrial  Hygiene  Survey 
(IHS)  form,  the  Occupational  Hazard  Data  Sheet  (OHDS)  and  the  Material  Inventory 
(MI).  Personnel  data  are  entered  into  the  industrial  component  via  a  link 
between  NOHIMS  and  the  Personnel  Extract  File  (PEF)  of  the  Naval  Air  Rework 
Facility.  The  contents  of  these  data  collection  vehicles  are  described  in 
further  detail  below. 

Industrial  Hygiene  Survey  (IHS)  Form.  The  IHS  form  is  used  to  collect 
facts  and  conditions  about  the  general  workplace.  The  industrial  hygienist  or 
safety  specialist  conducting  the  survey  completes  one  of  these  forms  for  every 
survey  that  is  performed.  The  form  contains  the  following  data  items:  the 
agency  surveyed,  the  environments  surveyed,  the  date  the  survey  was  conducted, 
the  type  of  survey  conducted,  the  supervisor  and  telephone  number  of  the 
workplace  surveyed,  who  prepared  the  survey  report,  a  description  of  operations 
at  the  workplace,  adverse  health  effects  reported  (including  the  worker's  name, 
social  security  number,  employee  number,  and  reported  symptoms),  engineering 
controls,  personal  protective  equipment  required  and  for  what  operations  the 
equipment  is  required,  deficiencies  in  the  environment(s) ,  and  recommended 
actions  for  implementation. 

Occupational  Hazard  Data  Sheet  (OHDS).  The  OHDS  is  used  for  gathering 
material  sampling  and  exposure  data  and  is  prepared  for  each  hazardous  agent 
sampled  in  an  environment.  When  the  survey  data  are  entered  into  NOHIMS,  the 
data  entry  clerk  may  enter  data  from  as  many  OIlDSs  as  is  necessary  to  fully 
describe  the  sampling  that  was  performed.  A  separate  OHDS  is  used  for  each 
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measurement  of  the  same  agent,  as  well  as  for  each  agent  sampled.  The  OHDS 
collects  the  following  data:  building  and  shop  identification,  the  date  the 
survey  was  conducted,  the  agent  sampled,  the  work  environment/operation/source, 
the  person  who  was  sampled,  personal  protective  equipment  in  use,  the  measured 
concentration  for  the  agent,  hazard  type,  sampling  strategy,  mode  of  entry, 
weekly  usage  rate,  continuity  of  process,  analytical  method,  sample  number,  date 
the  sample  was  taken,  sample  media,  flow  rate,  duration,  potential  hazard 
severity,  mishap  probability,  medical  monitoring  recommendation,  and  rationale 
for  the  medical  monitoring  recommendation. 

Material  Inventory  (MI).  The  MI  is  used  to  record  the  presence  of  each 
agent,  material,  or  product  found  in  the  environment.  The  Material  Inventory 
form  collects  the  environments  surveyed;  the  date  of  the  survey;  the  preparer  of 
the  report;  the  work  areas  covered;  and  a  list  of  the  products,  including 
specifications  and  manufacturer,  the  agents  contained  in  the  products,  the 
weekly  amount  used,  and  the  sampling  decision. 

Personnel  Extract  File  (PEF).  The  PEF  is  used  to  automatically  transmit 
personnel  data  for  Naval  Air  Rework  Facility  (NARF)  workers  to  NOHIMS.  The  data 
include  the  worker's  name,  social  security  number,  employee  number,  sex,  date  of 
birth,  occupational  code,  and  current  work  location.  The  data  from  this  file 
are  used  to  track  employees'  work  history.  By  linking  the  workers  to  specific 
environments  that  have  in  turn  been  linked  with  industrial  hygiene  surveys,  the 
exposures  of  the  individual  workers  can  be  determined. 


The  following  describes  the  main  function  and  features  of  each  module  and 
option  in  the  medical  component  of  NOHIMS.  The  reports  generated  by  the  medical 
component  and  the  data  collection  forms  used  to  gather  and  enter  data  into  the 
system  are  also  described. 


There  are  eight  primary  system  modules  available  for  use  in  the  medical 
component  of  NOHIMS.  Two  of  these  modules — Registration  and  Enter  Medical 
Data — are  used  to  either  enter  data  into  the  database  or  to  edit  already 
existing  data.  Three  modules — Display  Medical  Data,  Print  Medical  Data,  and 
COSTAR  Report  Generator-  -are  used  to  retrieve  and  display  the  medical  component 
information.  A  Mailbox  module  allows  the  system  users  to  send  messages  to  and 
receive  messages  from  other  system  users.  The  Occupational  Health  Information 
module  has  not  yet  been  implemented.  The  intention  is  that  it  will  take  the 
system  user  to  the  primary  system  menu  of  the  industrial  component.  The  eighth 
module  is  Systems  Maintenance.  This  module  is  used  to  initialize  system 
parameters  such  as  security  files,  to  maintain  the  system  directories,  and  to 
assure  the  integrity  of  the  database.  The  primary  system  menu  is  as  follows: 
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REGISTRATION 
ENTER  MEDICAL  DATA 
DISPLAY  MEDICAL  DATA 
PRINT  MEDICAL  DATA 
COSTAR  REPORT  GENERATOR 
SYSTEMS  MAINTENANCE 
MAILBOX 

OCCUPATIONAL  HEALTH  INFORMATION 

Registration  Module.  This  module  provides  for  the  entry,  edit,  and  display 
of  all  identifying  and  demographic  data  for  the  patient.  A  patient  rnust  be 
registered  in  the  medical  component  before  any  encounter  data  or  history  data 
can  be  entered  into  the  patient's  medical  record.  The  Registration  module  has 
the  following  two  system  options: 

PATIENT  REGISTRATION/EDIT 
DISPLAY  REGISTRATION 

Patient  Registration/Edit .  This  option  is  used  to  enter  a 
patient  and  his/her  demographic  information  into  NOHIMS.  Only  three 
data  elements  must  be  collected  during  registration:  the  patient's 
name,  sex,  and  date  of  birth.  The  NOHIMS  registration  sequence  has 
been  set  up  to  gather  other  data  elements  required  for  Navy  purposes. 

These  data  items  include  a  person  to  notify  in  emergency,  telephone 
number  in  emergency,  date  of  registration,  social  security  number 
(also  used  as  the  unit  number  to  uniquely  identify  the  patient  in 
NOHIMS),  duty  station  or  activity,  and  primary  clinic.  It  was  also 
intended  that  the  patient  registration  would  include  the  ethnic 
background  of  the  patient.  This  variable  has  not  yet  been  implemented 
in  NOHIMS.  A  policy  decision  needs  to  be  made  first  on  appropriate 
categories  for  the  ethnicity  code. 

The  registration  sequence  can  be  modified  using  the  Registration 
Functions  option  in  the  Systems  Maintenance  module.  The  Systems 
Maintenance  module  tells  the  system  which  data  elements  are  to  be 
collected,  in  what  order  they  are  to  be  collected,  and  how  the 
registration  data  are  to  be  displayed  on  a  terminal.  Help  text  is 
available  throughout  the  registration  process  to  assist  the  data  entry 
clerk  in  properly  entering  the  data.  The  entries  that  have  been  made 
are  usually  displayed  on  the  CRT  screen  as  the  data  entry  clerk 
registers  the  patient.  Any  incorrect  entries  can  be  edited  before  the 
registration  is  filed. 

This  option  is  also  used  to  edit  an  already  existing  patient 
registration.  None  of  the  registration  data  items  except  the  name  and 
social  security  number  is  kept  historically,  that  is,  the  new  value 
replaces  the  previous  value  for  the  given  data  item.  If  either  the 
patient's  name  or  social  security  number  are  modified,  NOHIMS  will 
enter  the  new  value  into  the  patient's  record  and  cross  reference  the 
file  to  the  old  value. 

Display  Registration.  Display  Registration  allows  the  user  to 
view,  on  either  a  CRT  or  printer,  the  complete  set  of  registration 
data  for  a  patient.  The  registration  display  for  NOHIMS  contains  the 


patient's  name,  sex,  date  of  birth,  person  to  notify  in  emergency, 
phone  number  in  emergency,  date  of  registration,  social  security 
number,  duty  station  or  activity,  and  primary  clinic. 

The  patient  to  be  displayed  can  be  identified  by  name  or  by 
social  security  number.  The  social  security  number  is  the  unit  number 
that  uniquely  identifies  the  patient  in  the  system.  The  patient  to  be 
displayed  can  be  identified  with  an  ambiguous  entry  of  the  name.  The 
minimum  number  of  letters  of  the  patient's  name  that  must  be  entered 
at  the  Identify  Patient  prompt  is  two  letters  of  the  last  name. 

NOHIMS  will  then  list  all  patient  registered  in  the  medical  component 
that  meet  the  criteria  entered.  NOHIMS  does  not  search  for  patient 
names  by  phonetics.  This  option  only  displays  registration  data.  No 
changes  can  be  made  to  the  registration  record  while  in  this  option. 

If  the  user  desires  to  edit  the  registration  record,  the  Patient 
Registration/Edit  option  must  be  used  to  display  and  then  edit  the 
registration  record. 

The  registration  display  format  may  be  formatted  as  a  consensus 
of  the  users  desire.  The  specifications  for  the  registration  display 
are  set  up  and  altered  via  the  Registration  Functions  option  of  the 
Systems  Maintenance  module. 

Enter  Medical  Data  Module.  The  Enter  Medical  Data  Module  allows  entry  and 
editing  of  patient  encounter  or  history  data  and  laboratory  results.  In  NOHIMS, 
an  encounter  is  a  set  of  data  that  describes  a  medical  visit,  a  physical 
examination,  or  a  patient's  occupational  or  medical  history.  More  than  one 
encounter  can  be  entered  on  a  given  day;  however,  the  COSTAR  Report  Generator 
does  not  always  retrieve  the  data  properly  when  this  is  done.  The  Enter  Medical 
Data  module  has  the  following  three  options: 

ENCOUNTER  ENTRY 
LAB  RESULTS 
MEDICAL  EDIT 

Encounter  Entry.  This  option  is  used  to  initially  enter  all 
encounter  data.  The  encounter  entry  format  has  two  parts — the  Header 
and  the  Body  of  the  encounter.  The  Header  contains  primarily 
administrative  information  that  identifies  the  patient,  the  date  and 
site  of  the  encounter,  the  name  of  the  care  provider(s),  and  the 
nature  of  the  visit  and  service  provided.  The  order  of  data  items 
entered  in  the  Header  is  fixed.  Entry  of  data  items  in  the  Body  of 
the  encounter  can  be  in  any  order;  however,  the  order  of  data  entry 
should  follow  the  items  on  the  medical  component  encounter  forms.  Lab 
test  codes  are  usually  entered  at  the  time  of  entering  the  encounter 
data.  Lab  results  can  be  entered  at  encounter  entry  or  they  can  be 
entered  at  a  later  date  using  the  Lab  Results  option.  Data  items  are 
entered  into  the  Body  of  an  encounter  by  entering  the  data  entry  code 
along  with  any  associated  items,  such  as  modifiers,  statuses,  or 
textual  comments.  Only  data  items  that  have  been  predefined  in  the 
medical  component  directory  can  be  entered.  Some  of  the  codes  have 
special  conditions  that  perform  value  checking;  some  codes  prompt  for 
textual  comment  while  others  require  a  modifier  to  be  entered.  If  an 
error  is  made  during  encounter  entry,  incorrect  entries  can  be 


corrected  by  re-entering  the  code  and  associated  data  in  the  correct 
manner.  The  new  entry  will  automatically  take  precedence  over  the 
previous  entry.  Data  items  may  be  flagged  as  an  erroneous  entry  by 
typing  an  "E/"  before  the  code.  Errored  out  data  items  no  longer 
appear  in  the  patient’s  medical  record. 

Lab  Results.  The  Lab  Results  option  is  used  to  enter  laboratory 
results  if  encounter  entry  has  already  been  completed.  Lab  Results 
uses  three  types  of  entry  methods.  Single  result  tests  simply  prompt 
for  the  results  of  the  test.  Multiple  result  tests  call  special 
programs  that  prompt  for  a  series  of  results.  Common  laboratory  tests 
of  this  type  include  Urinalysis  and  the  Pulmonary  Function  Tests. 

Individual  results,  such  as  Forced  Expiratory  Volume,  cannot  be 
retrieved  separately  from  the  main  code,  Pulmonary  Function  Test.  A 
third  type  of  entry,  called  a  listcode,  is  a  single  code  that  causes 
the  system  to  prompt  for  a  series  of  results  all  of  which  are  separate 
codes  in  the  system.  Complete  Blood  Count,  the  SMAC  panels,  and  the 
audiograms  are  examples  of  listcodes.  When  a  listcode  is  used,  the 
results  are  stored  with  the  individual  codes  and  are  only  retrievable 
via  the  individual  codes.  A  listcode  makes  data  entry  faster  because 
only  the  listcode  and  the  individual  results  need  to  be  entered;  the 
system  automatically  prompts  for  the  individual  results.  The  sequence 
and  list  of  codes  for  a  listcode  can  be  modified  by  selecting  the 
Directory  option  of  the  Systems  Maintenance  module.  Conditions  can  be 
associated  with  each  of  the  laboratory  test  codes  to  perform  value 
checking  to  determine  if  a  result  is  allowable  and/or  if  a  status  flag 
of  abnormal  should  be  set.  Textual  comments  may  also  be  entered  along 
with  the  test  results. 

Medical  Edit.  Once  Encounter  Entry  has  been  terminated,  edits  to 
the  encounter  record  must  be  made  through  the  Medical  Edit  option. 

After  selecting  to  edit  the  encounter,  data  from  the  header  of  the 
encounter  will  be  displayed.  The  user  may  then  edit  each  header  data 
item  or  accept  the  current  value  for  the  data  item.  In  the  body  of 
the  encounter,  corrected  entries  of  codes  and  associated  data  will 
replace  previous  entries.  The  user  may  also  modify,  delete,  or  add 
text  for  a  data  item  that  was  previously  enterd  by  re-entering  the 
code  and  selecting  to  edit  the  text.  Data  items  may  also  be  flagged 
as  erroneous  input  with  the  "E/"  status  code  entry.  An  entire 
encounter  may  be  flagged  as  erroneous  by  entering  "ERROR"  at  the  type 
of  encounter  prompt  in  the  Header  of  the  encounter.  Errored  entries 
are  not  deleted  from  the  patient's  record  in  order  to  maintain  an 
audit  trail.  They  are  merely  flagged  as  an  error  entry  and  bypassed 
by  data  retrieval  functions. 

Display  Medical  Data  Module.  The  Display  Medical  Data  module  allows  data 
in  the  medical  record  file  to  be  displayed  or  printed  in  a  variety  of  formats 
and  sequences.  The  reports  produced  by  the  Display  Medical  Data  module  include 
List  Encounters,  Encounter  Report,  Most  Recent  Encounter,  Flowchart,  Interactive 
Flowchart,  Index  Patient,  Status  Report,  Patient  Summary,  and  Registration  Data 
Check  (exactly  the  same  as  the  Patient  Display  in  the  Display  Registration 
option).  Encounter  Report  and  Most  Recent  Encounter  display  data  from  a  single 
encounter.  Flowchart,  Interactive  Flowchart,  Index  Patient,  Status  Report,  and 
Patient  Summary  summarize  data  across  encounters. 


Like  the  Display  Registration  option,  patients  for  whom  data  are  to  be 
displayed  can  be  identified  by  either  the  patient's  name  or  social  security 
number.  Ambiguous  entries  of  the  p-’.tient's  name  are  allowed.  In  the  Display 
Medical  Data  module,  the  patient  is  identified  prior  to  selecting  the  report 
that  is  desired.  Thus,  a  variety  of  reports  may  be  displayed  or  printed  for  a 
patient  without  having  to  identify  the  patient  each  time.  All  of  the  previously 
described  options  are  merely  display  options;  data  may  not  be  edited  while  in 
the  Display  Medical  Data  module.  Each  of  the  options  contains  help  text  at  the 
various  system  prompts  to  help  a  user  select  and  display  the  report  that  is 
desired.  Softcopies  of  the  reports  are  obtained  by  selecting  the  report  option 
while  logged  onto  a  CRT.  If  the  user  logs  onto  a  hardcopy  device,  hardcopies  of 
the  reports  may  be  obtained.  Hardcopies  of  the  reports  may  also  be  obtained  via 
the  Print  Medical  Data  module  described  next.  The  ability  to  display  reports 
can  be  restricted  to  certain  classes  of  users  and  to  certain  devices  to  maintain 
confidentiality  of  the  medical  data. 

List  Encounters.  This  option  produces  a  list  of  all  past  encounters 
for  the  patient  specified.  The  list  includes  the  date  of  the 
encounter,  the  site  and  type  of  the  encounter,  and  the  provider(s), 
thus  providing  the  user  with  enough  information  to  determine  which 
encounter  or  encounters  should  be  viewed  in  more  detail. 

Encounter  Report.  The  Encounter  Report  is  a  display  of  a  single  visit 
to  the  Occupational  Health  Unit.  There  are  two  main  encounter  types 
in  NOHIMS.  The  most  common  encounter  is  entered  from  the  Physical 
Exam  Data  Sheet  (PEDS)  and  the  Physical  Examination  Findings  (PEX) 
form.  If  a  patient  was  examined  as  part  of  the  Asbestos  Medical 
Surveillance  Program,  he/she  will  have  an  additional  encounter  for  the 
data  required  by  that  program.  When  the  occupational  and  medical 
history  data  collection  forms  are  implemented,  the  data  will  be 
entered  into  additional  encounters  separate  from  the  basic  PEDS  and 
PEX  encounter. 

The  Encounter  Report  retrieves  all  data  items  entered  for  the 
encounter.  The  format  for  the  data  in  the  Encounter  Report  cannot  be 
changed  without  programming  intervention.  The  Encounter  Report 
displays  a  header  with  the  patient’s  name,  sex,  date  of  birth,  current 
age,  unit  number  (SSN),  site  of  the  visit,  type  of  visit,  visit 
classification,  and  medical  care  providers.  The  remaining  data  are 
organized  by  divisions  of  the  medical  record  (Administrative, 

Diagnosis,  Physical  Findings,  Laboratory,  and  Disposition).  For  each 
coded  item,  NOHIMS  displays  the  internal  code  and  the  long  name  of  the 
code.  Modifier  names,  statuses,  textual  comments,  and  laboratory 
results  are  also  displayed,  if  any. 

The  user  selects  the  encounter  to  be  displayed  by  date  of  the 
encounter.  No  other  criteria  may  be  used  to  select  which  encounters 
are  to  be  displayed  with  this  option  except  otherwise  noted  below 
under  Most  Recent  Encounter. 

Most  Recent  Encounter.  Most  Recent  Encounter  allows  the  user  to 
display  or  print  an  encounter  report  for  the  most  recent  encounter  in 


41 


a  patient's  medical  record  or  to  progressively  view  several  encounters 
in  reverse  chronological  order. 


Flowchart .  Flowchart  allows  the  user  to  track  prespecified  data  items 
across  encounters.  The  flowcharts  present  medical  information  across 
the  horizontal  axis  of  a  display  with  corresponding  dates  of  entry 
into  the  medical  record  displayed  on  the  vertical  axis.  Modifiers, 
statuses,  textual  comments,  and  results  are  included  in  the  flowchart, 
if  applicable.  Seven  standard  flowchart  specifications  have  been 
stored  in  NOHIMS.  These  are  called  Hypertension,  Diabetes,  Red  Blood 
Cell  Count,  Congestive  Heart  Failure,  Kidney  Failure,  Urinalysis,  and 
Liver  Function  Tests.  Additional  flowchart  formats  may  be  defined 
using  the  Flowchart  Template  Edit  suboption  in  the  Directory  option  of 
the  Systems  Maintenance  module.  The  NOHIMS  system  manager  may  specify 
the  data  items  to  be  included  in  the  flowchart  and  dictate  the 
specific  format  of  the  flowchart  to  a  limited  degree.  Which 
encounters  are  to  be  summarized  by  the  Flowchart  may  not  be  specified. 

Interactive  Flowchart.  This  option  permits  the  user  to  define  a 
flowchart  for  a  particular  patient.  The  specifications  for  the  data 
items  to  be  included  in  the  flowchart  are  not  stored  in  the  system. 

If  a  user  enters  the  same  specif ications  frequently,  they  can  be 
stored  in  the  system  as  a  standard  flowchart  using  the  Flowchart 
Template  Edit  suboption.  The  interactive  flowchart  is  the  quickest 
way  to  track  a  single  data  item  through  the  patient's  medical  record. 
Interactive  Flowchart  has  the  same  limitations  and  general  format  as 
the  Flowchart  option  does. 

Index  Patient.  The  Index  Patient  option  displays  an  index  to  all  of 
the  sections  of  a  patient's  medical  record,  providing  a  quick  review 
of  the  main  features  of  the  record.  After  viewing  the  index  list,  the 
user  may  request  a  detailed  listing  of  any  or  all  sections,  or  an 
interactive  flowchart  based  on  the  information  displayed  in  the  index. 
The  format  for  this  report  is  fixed.  If  a  data  item  has  a  short  name, 
the  Index  Patient  option  will  display  the  short  name.  Since  most  of 
the  codes  in  NOHIMS  have  short  names  that  are  used  in  data  entry,  this 
report  will  not  be  useful  unless  the  user  is  very  familiar  with  all  of 
the  data  entry  codes. 

Status  Report.  The  Status  Report  summarizes  the  medical  record  for  a 
patient  in  a  predefined  format  that  cannot  be  changed  without 
programming  intervention.  It  is  a  summary  of  and  index  to  all 
divisions  of  the  patient's  medical  record.  The  report  may  be  produced 
in  its  entirety  or  by  selected  divisions.  For  each  data  item,  the 
Status  Report  displays  the  internal  code,  the  long  name,  and  the 
provider  who  most  recently  entered  the  data  item  into  the  patient's 
medical  record.  Most  recent  textual  comments  and  laboratory  results 
are  also  displayed. 

Patient  Summary.  This  option  summarizes  the  medical  record  for  a 
patient  in  a  user-defined  format.  Using  the  Patient  Summary  Functions 
suboption  of  the  Systems  Maintenance  module,  the  system  manager  may 
specify  for  each  division  the  types  of  data  to  be  included  in  the 
display  (date,  abnormal  flag,  name  of  the  code,  results,  text,  and 
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provider),  the  format  of  the  date  and  provider  name,  and  the  location 
of  each  data  item  on  the  page.  For  certain  divisions,  the  system 
manager  can  also  specify  that  only  data  from  the  previous  N  encounters 
and/or  the  previous  N  months  will  be  included  in  the  report.  In 
addition,  the  system  manager  may  specify  data  items  to  be  included  in 
an  optional  Data  Matrix.  The  Data  Matrix  summarizes  selected  data 
items  for  the  four  most  recent  encounters.  Different  Data  Matrix 
criteria  may  be  specified  for  age  and  sex  groups. 

Registration  Data  Check.  The  Registration  Data  Check  option  allows 
the  user  to  display  or  print  the  registration  data  for  the  selected 
patient  without  leaving  the  Display  Medical  Data  Module.  The  content 
and  format  of  the  data  are  controlled  by  the  Registration  Functions 
described  in  the  Display  Registration  section  above. 

Print  Medical  Data  Module.  The  Print  Medical  Data  module  is  used  to 
produce  all  routine  hardcopy  medical  data  printouts.  This  module  contains  three 
usable  options:  Daily  Encounter  Reports,  Halt  Daily  Encounter  Report  on 
Printer,  and  Special  Print.  A  fourth  option,  Scheduled  Visit  Print  that 
produces  Patient  Summaries  for  patients  scheduled  for  an  appointment  for  a  given 
date  and  provider ,  is  not  usable  in  NOHIMS  because  the  Scheduling  module  of 
COSTAR  was  not  implemented.  The  Scheduling  module  currently  available  in  COSTAR 
is  usually  considered  too  cumbersome  and  too  slow.  A  fifth  option,  Laboratory 
Result  Reporting,  also  was  not  implemented  in  NOHIMS. 

Each  of  the  Print  Medical  Data  options  contains  help  text  at  the  various 
system  prompts  to  help  a  user  select  and  print  the  reports  that  are  desired. 

The  ability  to  print  reports  can  be  restricted  to  certain  classes  of  users  and 
to  certain  devices  to  maintain  confidentiality  of  the  medical  data.  The  main 
features  of  each  of  the  Print  Medical  Data  options  are  described  below. 

Daily  Encounter  Reports.  This  option  allows  the  user  to  print 
reports  for  patients  who  had  an  encounter  entered  on  that  day  or  the 

five  days  previous  to  that  day.  The  user  may  select  to  print  an 

encounter  report,  a  status  report,  all  previous  encounters,  or 
combinations  thereof.  The  order  of  the  printed  reports  usually  is 
determined  by  the  system  manager.  The  order  may  be  (1)  by  patient's 
last  name  alphabetically,  (2)  by  order  of  input,  (3)  by  unit  number, 

or  (4)  by  order  of  the  last  two  digits  of  the  social  security  number 

(the  last  order  would  not  be  useful  for  the  NOHIMS  application).  The 
user  may  specify  the  device  that  is  to  print  the  reports. 

Halt  Daily  Encounter  Report  on  Printer.  The  Halt  Daily  Encounter 
Report  on  Printer  option  permits  the  device  printing  daily  encounter 
reports  to  be  halted  from  another  device. 

Special  Print.  Special  Print  allows  the  user  to  specify  a  group 
of  patients  for  whom  medical  reports  are  to  be  produced.  The  reports 
can  be  produced  according  to  a  list  of  names  that  is  input, 
alphabetically  by  patient's  last  name,  in  social  security  (unit) 
number  order,  or  by  the  last  digit  of  the  social  security  number  (the 
last  order  would  not  be  useful  for  the  NOHIMS  application).  The 
reports  to  be  printed  (i.e.,  the  Status  Report,  Most  Recent  Encounter, 
all  Encounters,  Registration  Data  Check,  Flowcharts,  or  any 
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combinations  thereof)  may  be  specified  for  each  patient  individually 
or  for  the  group  of  patients  as  a  whole.  Once  the  list  of  names  is 
created,  it  is  stored  in  the  database  associated  with  the  device  used 
to  create  the  list  for  future  use.  Special  print  files  may  be  edited, 
restarted,  and  deleted  from  the  system. 

COSTAR  Report  Generator  Module.  The  COSTAR  Report  Generator  module  (CRG) 
has  the  capability  of  providing  listings  and  cross  tabulations  of  any  variables 
contained  in  the  NOHIMS  database.  Additionally,  percentages,  totals,  and 
subtotals  may  be  computed  for  any  specif ed  distribution.  This  module  serves  to 
satisfy  data  retrieval  needs  not  met  by  the  standardized  reports  described 
above. 

An  option  called  Query  Language  is  also  included  in  the  CRG  module  menu. 
This  option  is  used  to  retrieve  data  with  the  Medical  Query  Language,  a  high- 
level  language  that  provides  an  alternative  and  more  powerful  method  of 
retrieving  data  from  the  database.  In  addition,  the  CRG  module  contains  five 
options  that  are  used  in  special  research  functions  by  the  Naval  Health  Research 
Center  (NRHC),  San  Diego  to  retrieve  specific  medical  component  data.  These 
options  reformat  the  data  into  a  fixed  length  record  that  can  be  written  to  tape 
and  interfaced  with  statistical  packages  on  other  systems.  The  options  in  the 
CRG  module  are  as  follows: 

CREATE/EDIT  REPORT 

RUN/RESTART  REPORT 

PRINT  TABLES  IN  WORKING  STORAGE 

EDIT  MANAGEMENT  REPORTING  VARIABLE  DIRECTORY 

LIST  MANAGEMENT  REPORTING  VARIABLE  DIRECTORY 

DELETE,  RENAME  OR  SAVE  REPORT 

FILE  CLEANUP 

WRITE  REPORT  LIST 

BUILD  ALPHA  FILE 

QUERY  LANGUAGE 

CONSTRUCT  SSN  GLOBAL 

CLEAR  SSN  GLOBAL 

PRODUCE  FIXED  LENGTH  RECORD 

TRANSFER  GLOBAL  TO  TAPE 

MOVE  SSNS  FROM  INDUS  UCI 

Create/Edit  Report.  The  Create/Edit  Report  option  is  used  to 
create  or  edit  the  specifications  for  a  CRG  report.  Through  a  series 
of  prompts,  the  user  specifies  the  mode  of  the  search  (patient  mode  or 
visit  mode),  selection  conditions  (if  any),  variables  to  be  listed  and 
the  display  format,  and  variables  to  be  tabulated.  The  report 
specifications  are  stored  in  the  system  under  a  user-selected  name  of 
up  to  20  characters.  The  report  specifications  may  be  altered  at  any 
time.  When  editing  the  report  specifications,  NOHIMS  displays  each 
specification.  The  user  may  then  change  the  specification  or  null 
through  the  prompt  to  retain  the  specification.  The  edited 
specifications  may  be  saved  to  the  same  report  name  or  to  a  new  report 
name. 


The  Create/Edit  Report  option  allows  the  user  to  specify  whether 
data  will  be  listed  or  tabulated  in  patient  mode  or  in  visit  mode.  If 
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the  patient  mode  is  selected,  one  line  in  the  list  and  one  tally  in  a 
tabulation  will  be  made  for  each  patient  that  meets  the  given 
selection  criteria.  If  the  visit  mode  is  chosen,  the  system  will 
utilize  one  line  in  the  listing  and  one  tally  in  the  tabulation  for 
each  encounter  entered  in  the  system  for  the  patient  that  meets  the 
selection  criteria. 

The  user  may  also  specify  up  to  approximately  22  selection 
criteria  for  defining  subsets  of  patients  to  be  listed  or  tabulated. 
Selections  may  be  made  on  the  basis  of  the  presence  or  absence  of  a 
data  item,  the  value  of  a  data  item,  or  the  presence  or  absence  of 
data  in  a  particular  division,  or  combinations  thereof.  The  user  may 
specify  alternate,  necessary,  nested  alternate,  or  nested  necessary 
conditions,  or  a  combination  thereof.  At  the  time  of  running  the 
report,  the  user  may  specify  a  range  of  encounter  dates  to  be  included 
in  the  tally.  If  a  range  of  encounter  dates  is  specified,  the  CRG 
will  only  search  encounters  for  those  dates  for  valid  data. 

Otherwise,  the  CRG  will  search  the  entire  database  for  valid 
encounters/ patients . 

The  listings  produced  by  the  CRG  may  include  divisions,  actual 
data  items,  or  data  associated  with  a  data  item  (results,  statuses, 
modifiers,  and  text).  The  user  may  also  modify  data  items  with 
selection  criteria  such  as  last,  most  recent,  number  of,  etc.  The 
format  for  the  listings  is  defined  by  the  user  within  certain 
parameters.  Data  items  are  listed  across  the  horizontal  axis  so  the 
user  is  limited  to  80  columns  of  data  on  a  CRT  or  132  columns  of  data 
on  a  hardcopy  device.  The  system  sets  default  values  for  all  data 
items,  such  as  field  title,  field  width,  and  data  format.  These 
default  values  may  be  overridden  by  the  user.  Listings  may  be 
produced  in  one  of  three  ways:  (1)  order  of  encounter  input, 

(2)  alphabetic  order  by  the  patient's  name,  or  (3)  encounter  date 
order. 

The  cross  tabulations  provided  by  the  CRG  may  be  on  divisions, 
actual  data  items,  or  data  associated  with  a  data  item  (results, 
statuses,  modifiers,  and  text).  The  user  may  also  modify  data  items 
with  selection  criteria  such  as  last,  most  recent,  number  of,  etc. 

The  user  may  define  one  set  of  up  to  3-way  tables  and  may  specify  the 
down,  across,  and  by  variables  within  certain  limits.  Variables  that 
require  a  new  category  for  each  unique  value  may  not  be  used  in  the 
across  position.  The  user  can  define  groupings  by  either  discrete 
categories  (e.g.,  male  and  female)  or  continuous  categories  (e.g.,  10- 
19  years  of  age).  The  user  may  select  to  generate  another  set  of 
tables  that  contains  percentages  and  may  specify  the  denominator  of 
the  percentages  (row,  column,  or  table  total,  or  combinations 
thereof).  NOHIMS  does  not  compute  means,  deviations  from  a  mean,  or 
other  statistics.  The  CRG  does  not  produce  graphic  representations  of 
data . 

Run/Restart  Report.  The  Run/Restart  Report  option  is  used  to  run 
a  set  of  report  specifications.  When  starting  a  CRG  run,  the  user  may 
specify  whether  the  report  should  be  double-spaced,  the  device  to  be 
used  to  run  the  report,  and  when  the  report  should  be  run.  In  telling 


the  system  when  to  run  a  report,  the  user  may  either  run  the  report 
right  away  or  the  user  may  job  queue  a  CRG  report.  To  job  queue  a 
report,  the  user  either  specifies  the  date  and  time  the  job  is  to  be 
run  or  links  the  job  to  previous  jobs.  The  user  also  specifies  the 
device  that  is  to  be  used  to  run  the  report.  Currently,  only  one  CRG 
report  may  be  run  at  a  time.  This  is  a  limitation  of  the  present 
operating  system,  however.  The  device  that  is  being  used  to  run  the 
report  will  be  tied  up  until  the  report  is  completed.  Hardcopy  of 
reports  may  be  obtained  by  running  the  CRG  report  on  a  hardcopy  device 
or  by  printing  the  working  storage  on  a  hardcopy  device.  Softcopies 
of  reports  may  be  obtained  by  running  the  report  on  a  CRT.  Report 
specifications  may  be  run  as  many  times  as  desired. 


Print  Tables  in  Working  Storage.  When  a  CRG  run  is  performed, 
the  listings  are  produced  as  the  CRG  proceeds  through  the  database  and 


are  not  stored  in  the  system.  When  a  tabulation  is  produced,  the 
tables  are  stored  in  a  working  file  to  be  printed  at  a  later  date,  as 
well  as  being  displayed  or  printed  at  the  time  of  the  run.  The  Print 
Tables  in  Working  Storage  option  is  used  to  print  the  tables  produced 
by  the  CRG  run. 


Edit  Management  Reporting  Variable  Directory.  This  option  allows 
the  system  user  to  edit  the  variable  directory  that  is  used  to  prepare 
the  CRG  reports.  Directory  variables  are  used  to  define  the  divisions 
of  the  medical  record;  code  modifiers  such  as  "most  recent,"  "last," 
and  "number  of";  and  variables  that  require  special  extraction 
instructions.  The  directory  variables  also  define  default  values  such 
as  field  name,  field  width,  and  data  format.  Directory  variables  may 
be  added  to,  deleted  from,  or  modified  with  this  option. 

List  Management  Reporting  Variable  Directory.  With  this  option, 
users  are  allowed  to  review  information  about  the  report  variables 
that  have  been  defined  for  NOHIMS.  The  display  includes  extract 
instructions  and  display  format  default  values. 

Delete,  Rename  or  Save  Report.  This  option  is  used  to  delete 
report  specifications  from  the  report  list  or  to  rename  report 
specifications.  In  either  case,  tables  in  working  storage  under  the 
old  report  name  will  be  deleted.  The  Delete,  Rename  or  Save  Report 
option  provides  a  faster  way  to  perform  these  operations  without  goi.  • 
through  the  detailed  steps  of  the  Create/Edit  Report  option. 


File  Cleanup.  This  option  is  used  to  delete  tabulation  tables 
from  the  CRG  working  storage.  The  tables  can  be  deleted  for 
individual  reports,  or  all  tables  can  be  deleted  at  one  time. 

Write  Report  List.  Write  Report  List  provides  a  listing  of  the 
report  specifications  stored  in  the  system.  The  listing  includes  the 
report  name,  the  last  system  user  to  create/edit  the  report,  the  date 
of  the  last  create/edit  operation,  and  a  short  user-selected 
description  of  the  report  specifications. 

Build  Alpha  File.  This  option  builds  a  file  of  patient  names  in 
the  order  that  they  were  entered  into  the  medical  component,  and  then 
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inverts  the  file  so  that  the  names  appear  in  alphabetical  sequence. 

This  file  is  then  used  by  the  CRG  when  searching  the  database  in 
patient  name  alphabetic  order. 

Query  Language.  The  Medical  Query  Language  provides  a  more 
powerful  tool  for  selecting  and  retrieving  data  than  the  CRG.  For 
complicated  queries,  however,  the  Medical  Query  Language  requires  more 
effort  on  the  part  of  the  user  to  understand  the  content  and  format  of 
NOHIMS'  data  files  and  the  Medical  Query  Language's  programming-like 
conventions.  The  Medical  Query  Language  calculates  sums,  means,  sum 
of  squares,  and  standard  deviations.  It  also  has  the  ability  to  graph 
up  to  three  variables.  The  Naval  Health  Research  Center  has  a  3-year 
license  to  evaluate  the  potential  of  the  Medical  Query  Language  as  an 
enhancement  for  NOHIMS.  Use  of  the  Medical  Query  Language  could 
possibly  overcome  NOHIMS'  limitations  in  retrieving  correlated  data 
from  both  system  components. 

Construct  SSN  Global,  Clear  SSN  Global,  Produce  Fixed  Length 
Record,  Transfer  Global  to  Tape,  Move  SSNs  from  Indus  UCI .  These  five 
options  are  used  to  retrieve  certain  data  and  reformat  it  into  a 
fixed-length  record  that  can  be  used  with  other  statistical  packages. 

The  Construct  SSN  Global  option  uses  normal  CRG  procedures  to  select 
specified  patients  and  stores  the  patients'  social  security  numbers  in 
a  special  file.  The  Clear  SSN  Global  is  used  to  delete  all  of  the 
social  security  numbers  in  the  special  file.  The  Produce  Fixed  Length 
Record  option  extracts  certain  demographic  data  and  specified  physical 
examination  findings  and  laboratory  results  and  reorganizes  them  into 
a  fixed  format.  The  Transfer  Global  to  Tape  option  writes  the  fixed 
format  data  to  tape  for  transfer  to  other  systems.  The  Move  SSNs  from 
Indus  UCI  option  transfers  lists  of  social  security  numbers  produced 
via  the  Query/Report  module  of  the  industrial  component  into  the 
medical  component.  The  lists  of  social  security  numbers  may  be 
combined  with  another  list  in  the  medical  component,  or  a  new  list  may 
be  created  in  the  medical  component. 

Systems  Maintenance  Module.  The  Systems  Maintenance  module  consists  of  13 
functions  that  define  and  maintain  system  parameters  and  directories,  manage  the 
activities  that  insure  the  integrity  of  the  database,  and  manage  system 
operations  such  as  the  job  queue  and  transaction  control.  Systems  Maintenance 
contains  the  following  options: 

TRANSACTION  CONTROL 

SECURITY 

DIRECTORY 

REGISTRATION  FUNCTIONS 
SCHEDULING  FUNCTIONS 
ACCOUNTING  FUNCTIONS 
MEDICAL  DATA  FUNCTIONS 
ZIP  CODE  EDIT 
RECOVERY 

JOB  QUEUE  FUNCTIONS 
USER  PROFILE 

COSTAR  DIRECTORY  CODE  REVIEW 
SOFTWARE  PERFORMANCE  REPORT  (SPR) 


Transaction  Control.  Transaction  Control  managers  "Monitor,"  the 
background  "caretaker"  job  that  secures  the  system  against  data  loss. 
Two  suboptions — Start  Monitor  and  Halt  Monitor — change  the  status  of 
Monitor.  Inquiry  describes  the  current  status  of  Monitor  as  the 
system  perceives  it.  It  indicates  the  status  of  Monitor  (normal, 
crashed,  or  quiescent)  and  indicates  whether  Monitor  is  caught  up  with 
filing  transactions.  Two  other  suboptions — Error  Display  and  Print 
Errors — are  used  to  display  or  print  software  and  hardware  errors 
recorded  by  the  medical  component's  error  trapping  system.  A  special 
mode  in  Error  Display  will  recreate  the  system  parameters  at  the  time 
of  the  error  to  aid  in  investigating  the  error. 

Security .  The  Security  option  allows  the  system  manager  to 
customize  the  system  security  for  the  particular  application  site. 
Various  levels  of  security  may  be  specified.  The  ID  File  option 
defines  users  of  the  system.  The  name,  job  classification,  ID  code 
(log-on  code),  and  other  identifying  information  are  recorded  for  each 
user.  This  option  also  allows  the  system  manager  to  look  up  users, 
edit  information  for  users,  de-activate  users,  and  to  re-active  users. 
List  ID  File  allows  the  system  manager  to  view  the  current  ID 
information  found  in  the  ID  File  for  each  user  entered  in  the  system. 
The  Classification  File  option  permits  the  application  site  to  specify 
the  user  categories  at  the  application  site.  Usually  the  categories 
include  system  managers,  programmers,  physicians,  nurses,  and  data 
entry  clerks.  This  option  is  also  used  to  specify  which  modules  and 
options  are  accessible  to  each  class  of  user.  Option  Password  Edit  is 
used  to  define  and  edit  passwords  for  the  system  options,  if  this 
level  of  security  is  desired.  Device  Table  allows  the  system  manager 
to  define  the  devices  that  will  access  the  system  and  their 
characteristics  such  as  softcopy  versus  hardcopy,  lines  per  screen, 
characters  per  line,  etc.  The  system  manager  also  specifies  the 
system  options  that  are  accessible  with  each  device.  A  Cursor  Types 
option  is  available  for  use  if  a  new  terminal  type  needs  to  be  defined 
for  the  system. 

Directory .  This  option  permits  the  display  and  manipulation  of 
the  medical  component  directory.  Add  Code  allows  you  to  add  a  code  to 
the  directory.  Edit  Code  permits  the  system  manager  to  edit 
characteristics  (such  as  modifiers,  names,  and  check  results)  of 
directory  codes.  Code  Review  allows  the  user  to  view  the 
characteristics  for  a  directory  code.  Display  Directory  and  Print 
Directory  allow  the  user  to  display  or  print  all  or  part  of  the 
medical  component  directory.  Various  suboptions  determine  the  amount 
of  information  that  is  displayed  or  printed.  Codes  may  be  listed  in 
either  internal  code  order  or  alphabetic  order  by  the  code  name. 
Initialize  Translation  Directory  and  Translation  Directory  Edit  create 
or  maintain  translation  directories  for  billing  purposes  and  are, 
therefore,  not  used  for  NOHIMS.  Revenue  Center  Edit  permits  the 
definition  and  editing  of  revenue  centers  used  in  billing  functions. 
Again,  this  option  is  not  used  for  NOHIMS.  FI  “chart  Template  Edit  is 
used  to  define,  alter,  delete,  and  list  specifications  for  flowcharts 
that  are  accessible  via  the  Flowchart  option  in  the  Display  Medical 
Data  module. 
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Registration  Functions.  Registration  Functions  allows  editing  of 
the  registration  set-up.  The  parameters  in  this  option  tell  the 
system  which  data  elements  are  to  be  collected  during  the  registration 
sequence,  in  what  order  they  are  to  be  collected,  and  how  the 
registration  data  are  to  be  displayed  on  a  terminal.  The  system 
manager  may  format  the  registration  display  in  any  manner  that  is 
desired  and  define  item  headers  (names).  Only  one  registration 
display  format  is  used  by  the  system  at  one  time.  However,  two 
registration  display  formats  may  be  saved  in  the  system. 

Scheduling  Functions.  These  functions  initialize  the  provider 
schedule  templates  and  create  and  edit  directories  for  clinic 
definition,  types  of  visits,  and  clinic  holidays.  The  Scheduling 
module  was  not  initialized  for  NOHIMS. 

Accounting  Functions.  These  suboptions  create,  edit,  and  purge 
accounts  or  accounting  directories.  Other  accounting  functions  are 
also  maintained  via  these  options.  NOHIMS  does  not  use  the  billing 
portion  of  COSTAR. 

Medical  Data  Functions.  Medical  Data  Functions  has  four 
suboptions.  Patient  Summary  Functions  is  used  to  change  the 
parameters  for  the  Patient  Summary  report.  For  each  division,  the 
system  manager  specifies  the  types  of  data  to  be  included  in  the 
display  (date,  abnormal  flag,  name  of  the  code,  results,  text,  and 
provider),  the  format  of  the  date  and  provider  name,  and  the  location 
of  each  data  item  in  the  display.  For  some  divisions,  the  system 
manager  can  also  specify  that  only  data  from  the  previous  N  encounters 
and/or  the  previous  N  months  will  be  included  in  the  report.  The 
system  manager  may  also  specify  data  items  to  be  included  in  an 
optional  Data  Matrix.  The  Data  Matrix  summarizes  selected  data  items 
for  the  four  most  recent  encounters.  Different  Data  Matrix  criteria 
may  be  specified  for  age  and  sex  groups.  Edit  Encounter  Input 
Parameters  may  be  used  to  alter  certain  parameters  for  the  encounter 
header  sequence.  The  features  which  can  be  invoked  in  this  suboption 
are  not  applicable  to  NOHIMS;  therefore,  this  option  does  not  need  to 
be  used  with  NOHIMS.  Archive  Patient  Records  may  be  used  to  offload 
inactive  patient  records  to  tape  or  to  recall  patient  records  from 
tape.  The  user  may  select  individual  records  or  a  certain  group  of 
records  to  be  archived  or  de-archived.  The  Visit  Classification  Code 
Listing  contains  the  current  Visit  Classification  Code  List  as 
developed  for  NOHIMS.  This  option  is  merely  a  review  function. 

Changes  to  the  Visit  Classification  Code  Listing  are  made  using  the 
Directory  option. 

Zip  Code  Edit.  The  Zip  Code  Edit  option  can  be  used  to  add  a  zip 
code  and  its  associated  city  and  state  to  the  zip  code  directory,  to 
delete  a  zip  code  from  the  directory,  or  to  modify  the  city  and  state 
associated  with  a  zip  code.  A  listing  of  the  zip  code  directory  may 
also  be  obtained.  NOHIMS  supports  five  digit  zip  codes. 

Recovery .  The  Recovery  function  must  be  used  when  hardware  or 
software  malfunctioning  has  resulted  in  loss  or  damage  to  the 
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database.  If  this  should  occur,  programming  support  will  be  required 
to  initiate  the  recovery  process.  This  option  restarts  operations 
after  the  system  crash.  It  essentially  duplicates  all  of  the  filing 
activities  that  have  taken  place  since  the  last  disk  or  magnetic  tape 
back-up  was  performed. 

Job  Queue  Functions.  Certain  jobs  may  require  major  system 
resources  to  run  to  completion,  such  as  printing  special  reports  and 
running  report  generator  reports.  Typically,  these  jobs  are  placed  in 
a  job  queue,  scheduled  to  run  at  a  particular  point  in  time.  Job 
Queue  Functions  allows  the  system  manager  to  list,  edit,  or  examine 
the  current  job  queue.  Jobs  may  also  be  deleted  from  the  job  queue 
with  this  option. 

User  Profile.  This  option  displays  the  current  users  of  the 
medical  component  giving  the  job  number,  UCI ,  location  of  the  device, 
the  NOHIMS  user,  the  routine  being  used,  and  the  device  number  in  use. 

This  option  can  also  be  used  to  verify  that  the  "Monitor"  is  running. 

COSTAR  Directory  Code  Review.  This  option  is  the  same  as  the 
Code  Review  suboption  under  Directory.  Because  it  only  allows  review 
of  the  characteristics  of  a  code,  it  is  a  safe  option  to  give  to 
system  users  who  should  not  have  access  to  the  directory  maintenance 
options — Edit  Code  and  Add  Code. 

Software  Performance  Report  (SPR).  A  system  user  can  use  this 
option  to  document  program  errors  or  system  bugs  for  later  review  by 
the  system  manager.  It  also  has  a  test  function  that  allows  features 
of  the  system  to  be  tested  while  the  testing  process  is  automatically 
being  logged. 

Mailbox  Module.  The  Mailbox  module  provides  the  capability  for  users  of 
the  medical  component  to  send  messages  to  each  other.  The  system  manager  may 
also  send  messages  of  general  importance  to  all  system  users.  The  system 
manager's  messages  display  automatically  following  the  log-on  procedure.  If  the 
user  has  a  personal  message,  NOHIMS  will  indicate  this  by  announcing  "YOU  HAVE 
MAIL"  after  the  acknowledgment  of  the  user  during  log-on.  The  Mailbox  has  the 
following  three  system  options: 

SEND  MAIL 
PRINT  MAIL 
DELETE  MAIL 

Send  Mail.  This  option  is  used  to  send  mail  to  another  system 
user  or  to  create  a  system  manager's  message.  The  option  has  a  simple 
text  editor  to  edit  messages  before  they  are  filed  and  sent  to  the 
recipient(s) . 

Print  Mail.  When  the  user  receives  a  "YOU  HAVE  MAIL"  message, 
he/she  may  use  the  Print  Mail  option  to  view  the  message(s).  If  the 
user  has  more  than  one  message,  he/she  may  select  the  messages  to  be 
viewed.  The  messages  may  be  viewed  as  many  times  as  desired. 
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Delete  Mail.  The  system  users  uses  the  Delete  Mail  option  to 

delete  messages  when  they  are  no  longer  needed.  The  user  may  either 

delete  all  messages  or  selectively  delete  messages. 

Occupational  Health  Information  Module.  This  option  was  intended  to 
directly  take  the  user  to  the  main  menu  of  the  industrial  component  of  NOHIMS. 
Selection  of  the  Occupational  Health  Information  module  would  provide  the  main 
avenue  of  access  from  the  medical  component  of  NOHIMS  to  the  industrial 
component  of  NOHIMS.  This  module  has  not  yet  been  implemented.  Instead,  if 
users  want  to  access  the  industrial  component,  they  must  exit  the  medical 
component  and  log  on  to  the  industrial  component  system. 

Description  of  Medical  Component  Data  Collection  Forms 

The  data  collection  forms  for  the  medical  component  consist  of  a  Patient 
Registration  form,  four  encounter  forms,  and  forms  that  collect  laboratory  test 
results.  The  four  encounter  forms  are  the  Physical  Exam  Data  Sheet  (PEDS)  and 
the  Physical  Examination  Findings  (PEX)  form  which  make  up  one  encounter,  the 
Asbestos  Surveillance  Form  (NAVMED  6260/5),  a  Medical  History  (MEDHX)  form,  and 
an  Occupational  History  (OCCHX)  form.  All  of  these  forms  except  the  Asbestos 
Surveillance  Form  were  designed  specifically  for  NOHIMS  at  the  Occupational 
Health  Unit,  North  Island,  San  Diego.  All  but  one  of  the  laboratory  test  and 
procedure  result  data  collection  forms  are  standard  Navy  forms.  An  EKG  Results 
form  was  designed  for  entering  EKG  results  and  interpretation  into  NOHIMS.  The 
contents  of  all  of  these  forms  is  describe  i  below. 

Patient  Registration  Form.  The  Patient  Registration  form  is  completed  by 
the  patient  the  first  time  that  he/she  has  a  physical  examination  at  the 
Occupational  Health  Unit.  The  form  collects  the  following  items:  patient  name, 
sex,  date  of  birth,  person  to  notify  in  emergency,  telephone  number  in 
emergency,  date  of  registration,  social  security  number,  duty  station  or 
activity,  and  primary  clinic.  Once  a  policy  decision  is  reached  on  appropriate 
ethnic  categories  for  NOHIMS,  an  ethnic  background  data  item  will  be  added  to 
the  Registration  form. 

Physical  Exam  Data  Sheet  (PEDS).  The  first  page  of  the  PEDS  form  is 
completed  by  the  patient  at  each  encounter.  The  remaining  parts  of  the  form  are 
completed  by  the  occupational  health  technician  based  on  the  Individual  Exposure 
Examination  Report  produced  by  the  industrial  component  of  NOHIMS.  The  PEDS 
form  collects  the  following  data:  patient  name,  sex,  date  of  birth,  care 
provider(s),  date  of  the  encounter,  social  security  number,  site  of  the 
encounter,  type  of  examination,  visit  classification,  work  information 
(including  job  title,  work  supervisor,  building  number,  shop  number,  and  shop 
telephone),  job  certifications  (if  appropriate),  hazardous  agent  surveillance, 
protective  equipment  examinations,  laboratory  tests  (including  radiologies, 
pulmonary  function  tests,  electrocardiograms,  and  audiograms),  and  an  indication 
of  whether  an  eye  examination  is  required. 

Physical  Examination  Findings  (PEX).  The  first  part  of  the  PEX  form  is 
completed  by  the  occupational  health  technician.  These  data  items  include  the 
patient's  social  security  number,  type  of  physician  examination,  height,  weight, 
and  vital  signs.  The  physician  completes  the  rest  of  the  form.  These  data 
items  include  the  medical  care  provider  giving  the  examination,  physical 
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findings  for  a  variety  of  body  systems  (including  general  appearance,  skin, 
eyes,  ears,  nose,  oral  cavity,  neck,  thorax  and  lungs,  female  breast,  heart, 
axillae,  abdomen,  female  genitals,  male  genitals,  rectal,  back,  extremities  and 
joints,  neuropsychiatric,  vascular  system,  and  other  findings),  a  problem  list, 
and  disposition.  The  physical  findings  sections  allow  the  physician  to  record 
if  the  examination  was  omitted  or  refused,  normal,  or  abnormal.  If  there  are 
abnormalities,  the  physician  indicates  the  type(s)  of  abnormalities.  Each 
examination  has  room  for  comments  as  well.  The  problem  list  includes  an 
indication  of  status  (e.g.,  inactive,  history  of,  or  rule  out)  and  the  ICD-9-CM 
code. 

Asbestos  Surveillance  Form  (NAVMED  6260/5).  The  standard  form  for  the 
Asbestos  Medical  Surveillance  Program  is  used  by  NOHIMS  to  capture  data 
regarding  asbestos  examinations.  The  form  is  completed  by  the  physician.  The 
data  entry  clerk  uses  an  overlay  to  enter  the  data  directly  from  the  standard 
Navy  form.  The  data  items  that  are  entered  from  the  Asbestos  Surveillance  Form 
are  as  follows:  the  patient  name,  sex,  date  of  birth,  date  of  the  encounter, 
site  of  the  encounter,  type  of  encounter,  and  all  of  the  data  items  under  the 
Repiratory  Questionnaire  and  Respiratory  Physical  Examination.  The  medical  care 
provider  name  is  taken  from  the  PEX  form. 

Medical  History  (MEDHX) .  The  MEDHX  form  is  an  experimental  form  and  is  not 
in  current  use  at  the  Occupational  Health  Unit.  The  form  was  intended  to  be 
completed  by  the  patient  and  then  reviewed  by  the  physician.  The  MEDHX  covers 
the  following  areas  of  medical  history:  family  history,  past  medical  history 
(including  allergies,  immunizations,  medicines,  hospitalizations  and  operations, 
injuries,  and  treatments),  personal  history  (including  smoking,  exercise,  and 
alcohol  use  history),  and  review  of  systems  (covering  skin,  eyes,  ears  and 
hearing,  nose/throat/sinuses/mouth/teeth/gums,  respiratory  system, 
cardiovascular  system,  gastrointestinal  system,  urinary  and  reproductive 
systems,  musculoskeletal  system,  nervous  system,  and  miscellaneous). 

Occupational  History  (OCCHX).  The  OCCHX  is  another  experimental  form  that 
is  not  in  current  use  at  the  Occupational  Health  Unit.  The  form  is  to  be 
completed  by  the  patient  and  reviewed  by  one  of  the  medical  care  providers.  The 
form  gathers  data  on  the  following:  occupational  exposure  inventory  (including 
work-related  illness,  injuries,  and/or  symptoms),  environmental  history 
(including  home  exposures,  and  hobbies  and  crafts),  and  a  chronological 
occupational  profile  for  all  jobs  after  high  school  or  age  18.  The 
chronological  profile  includes  employment  status  (such  as  type  of  job,  industry, 
time  worked,  and  duties),  job-related  health  problems  or  injuries,  health 
hazards  on  the  job,  and  protective  equipment  used. 

ERG  Results  Form.  The  identifying  information  on  the  ERG  Results  form  is 
completed  by  the  occupational  health  technician.  These  data  items  include  the 
patient  name,  sex,  date  of  birth,  and  date  of  the  ERG.  The  physician  reviews 
the  ERG  printout  and  marks  whether  the  ERG  was  normal,  questionable,  or 
abnormal.  The  physician  may  also  include  comments. 

Reference  Audiogram  (DP  2215).  The  Reference  Audiogram  is  completed  by  the 
care  provider  who  administers  the  audiogram.  This  is  the  standard  form  for  the 
Hearing  Conservation  Program.  The  data  entry  clerk  uses  an  overlay  to  enter  the 
data  into  NOHIMS.  The  data  items  that  are  entered  into  the  medical  component 
from  the  DD  2215  include  the  following:  the  date  of  the  audiogram,  day  of  the 


week  of  the  audiogram,  military  time  of  the  audiogram,  hours  since  last  noise 
exposure,  and  values  for  the  Hearing  Threshold  Levels  for  the  left  and  right 
ears. 

Hearing  Conservation  Data  Form  (DP  2216).  This  form  is  also  completed  by 
the  care  provider  who  administers  the  audiogram.  This  is  a  standard  form  for 
the  Hearing  Conservation  Program.  Again,  the  data  entry  clerk  uses  an  overlay 
to  enter  the  data  into  NOHIMS.  The  data  items  that  are  entered  into  the  medical 
component  from  the  DD  2216  include  the  following:  the  date  of  the  reference 
audiogram,  values  for  the  Hearing  Threshold  Levels  for  the  left  and  right  ears 
for  both  the  current  audiogram  and  the  reference  audiogram,  and  values  for  the 
Threshold  Shifts  for  each  Hearing  Threshold  Level  for  each  ear. 

Pulmonary  Function  Test  Results.  The  data  for  Pulmonary  Function  Tests  are 
taken  directly  from  the  patient's  paper  medical  record.  The  results  strip  from 
the  Pulmonary  Function  testing  machine  is  stapled  to  the  chart.  The  physician 
reviews  the  results  and  notes  whether  the  test  was  normal,  abnormal,  or 
questionable.  He/she  may  also  write  a  comment  in  the  chart.  The  data  entry 
clerk  enters  the  data  from  the  "Best  Tests"  section  of  the  strip,  the 
physician's  impression  of  the  results,  and  comments,  if  any. 

Report  of  Radiologic  Consultation.  The  data  for  radiology  procedures  are 
entered  into  NOHIMS  from  the  Report  of  Radiologic  Consultation.  When  the 
physician  reviews  the  radiology  report,  he/she  notes  on  the  report  whether  the 
radiograph  was  within  normal  limits,  no  evidence  of  disease,  questionable,  or 
had  a  positive  finding.  The  physician  underlines  comments  that  are  to  be 
entered  into  the  medical  record  as  text. 

Hematology  Results  (549),  Chemistry  Test  Results  (including  SMAC  panel 
read-out),  Heavy  Metal  Test  Results  (557),  Urinalysis  Results  (550),  and 
Miscellaneous  Results  (551).  These  standard  Navy  lab  chits  are  used  to  enter 
the  test  results  into  NOHIMS.  Once  the  physician  has  reviewed  the  lab  chits, 
the  results  are  entered  into  the  system  from  the  lab  chits  by  the  data  entry 
clerk. 


DESCRIPTION  OF  SOFTWARE  QUALITY  ATTRIBUTES 

The  following  sections  describe  NOHIMS'  software  quality  attributes.  The 
topics  covered  are  the  usability  of  NOHIMS,  the  reliability  of  NOHIMS,  NOHIMS' 
error  recovery  and  back-up  procedures,  the  efficiency  of  NOHIMS  source  program 
code,  the  hardware  independence  of  NOHIMS,  and  the  maintainability  of  NOHIMS. 


Usability 

The  industrial  component  of  NOHIMS  provides  the  capabilities  necessary  to 
input,  store,  edit,  retrieve,  and  display  various  workplace  monitoring  data, 
including  work  history  data,  data  on  exposure  episodes,  environmental  monitoring 
and  industrial  hygiene  data,  and  worker  demographic  data.  It  is  limited  to 
retrieving  and  displaying  current  data  such  as  present  exposures  and  workplace 
assignments.  Historical  data  for  many  variables  are  retained  in  the  industrial 
component's  data  files,  although  at  present  these  data  cannot  be  retrieved.  The 


medical  component  of  NOHIMS  provides  functions  for  inputting,  storing,  editing, 
retrieving,  and  displaying  occupational  health  data,  including  data  from 
preplacement/employment  physical  examinations,  medical  surveillance 
examinations,  job  certification  examinations,  fitness  for  duty  and  return  to 
work  interactions,  audiometric  data,  biomedical  monitoring  data,  and  basic 
medical  and  demographic  data.  It  does  not  presently  have  the  capability  of 
inputting  illness  and  injury  care  data.  However,  the  Naval  Health  Research 
Center  is  currently  developing  data  collection  forms  and  making  changes  to  the 
COSTAR  directory  to  allow  illness  and  injury  care  data  to  be  processed  by 
NOHIMS.  Both  components  have  limited  capabilities  for  storing  and  processing 
occupational  health  program  management  data.  The  medical  component  of  NOHIMS 
can  provide  tallies  of  various  process  measures  such  as  the  number  of  physical 
examinations  conducted  and/or  the  number  of  laboratory  tests  performed.  NOHIMS 
can  provide  composite  summaries  of  various  medical  and  exposure  data;  however, 
only  a  few  links  between  medical  data  and  exposure  data  exist.  Extensive 
operational  testing  has  been  conducted  on  NOHIMS  as  part  of  this  evaluation. 

The  results  of  this  functional  testing  are  described  in  the  Operational  Testing 
of  NOHIMS  section  of  this  report.  In  addition,  subjective  assessments  of  the 
performance  of  NOHIMS  by  the  users  of  the  system  are  contained  in  the  Assessment 
of  Overall  System  Performance  section. 


Reliability 

NOHIMS  is  considered  to  be  a  very  reliable  system  at  this  point.  No 
changes  were  made  to  the  data  storage  or  retrieval  functions  of  public  domain 
COSTAR  for  NOHIMS.  Thus,  the  medical  component  of  NOHIMS  is  based  on  a  software 
package  that  has  been  extensively  tested  in  the  field  for  the  past  ten  years. 

The  only  bug  in  data  retrieval  functions  that  the  contracted  NOHIMS  developers 
are  aware  of  is  in  the  COSTAR  Report  Generator  when  more  than  one  encounter  is 
entered  for  a  patient  on  a  given  day.  The  COSTAR  Report  Generator  does  not 
differentiate  which  encounter  the  data  for  that  date  is  associated  with  and  may 
tally  data  items  multiple  times  if  certain  precautions  are  not  taken.  This 
problem  in  public  domain  COSTAR  has  been  documented  by  the  contracted  developers 
for  the  Naval  Health  Research  Center  (NHRC).  The  industrial  component  of  NOHIMS 
has  been  field  tested  for  three  years  and  all  of  the  known  bugs  in  data 

retrieval  and  storage  processes  have  been  worked  out. 

The  general  user  cannot  intentionally  or  unintentionally  corrupt  the  NOHIMS 
databases.  The  general  user  has  no  access  to  cross  references,  pointers,  or 
data  files.  Extensive  error  and  interrupt  trapping  prevents  the  user  from 
gaining  access  to  the  operating  system.  The  system  manager  or  someone  who 
enters  the  system  via  the  programmer's  access  code  could  potentially  corrupt  the 
databases,  so  these  people  must  take  great  care  when  working  in  the  system. 

NOHIMS  can  resolve  extraneous  or  ambiguous  input.  In  most  data  fields 
NOHIMS  has  some  anticipation  of  the  type  of  input  to  be  expected.  Validity  of 
the  input  is  checked  either  through  pattern  matching  or  by  whether  a  data  item 
(such  as  a  code,  variable  name,  or  patient  name)  already  exists  in  the  system. 

If  the  data  item  does  not  exist  in  the  system,  NOHIMS  will  produce  a  list  of 

choices  that  closely  approximates  the  input  received. 


Error  Recovery  Procedures 

Both  the  medical  and  industrial  components  of  NOHIMS  have  system  functions 
that  aid  in  recovering  data  if  an  error  occurs  or  if  the  system  crashes.  If  a 
"hard"  computer  crash  occurs  during  a  filing  operation,  the  global  files  may  be 
corrupted.  The  industrial  component  has  internal  integrity  check  operations 
that  search  the  global  files  and  record  any  erroneous  filing  conditions  that  are 
found.  Usually,  the  condition  can  be  corrected  through  execution  of  an 
automatic  correction  process.  This  process  is  capable  of  both  interpreting  the 
error  records  that  the  integrity  checking  routines  recorded  and  performing  the 
necessary  corrections  to  the  files. 

The  medical  component  of  NOHIMS  does  not  have  internal  integrity  check 
functions  in  case  of  a  hard  crash.  Instead,  the  system  relies  on  operating 
system  utilities  to  identify  and  repair  system  level  errors  such  as  physical 
disk  structure  pointers  and  on  a  manual  review  of  the  error  log  to  identify 
filing  sequence  errors.  If  filing  sequence  errors  have  occurred,  these  will 
require  either  programming  intervention  or  re-entry  of  data.  Monitor,  the 
background  job  that  directs  the  filing  functions,  is  a  single-feed  process.  In 
other  words,  it  files  data  from  one  encounter  at  a  time.  Therefore,  if  an  error 
does  occur  during  filing,  the  damage  is  limited  to  at  most  one  patient  record. 
The  medical  component  also  logs  "soft"  errors  that  occur  during  filing  with 
system  messages  to  help  detect  corrupted  patient  records  or  flag  potential 
filing  problems.  A  careful  review  of  the  error  log  at  least  daily  for  both  hard 
and  soft  errors  will  help  prevent  future  or  more  serious  errors  through  early 
detection  of  problems  or  identification  of  potential  trouble  spots. 

Back-Up  Procedures 

It  is  recommended  that  the  entire  NOHIMS  system  be  backed  up  on  another 
disk  at  least  daily.  Another  periodic  back-up  copy  should  be  kept  offsite.  If 
these  hard  disk  copies  are  adequately  checked  for  integrity,  they  will  provide 
the  necessary  back-up  for  the  system.  In  the  event  of  a  data  crash,  a  disk 
back-up  can  be  restored  easily.  At  most,  data  input  since  the  last  back-up  was 
made  would  need  to  be  re-entered.  Since  virtually  all  data  entered  into  NOHIMS 
are  entered  from  hard  copy,  it  is  relatively  easy  to  keep  an  audit  trail  of  data 
entry.  The  operating  systems  that  support  MUMPS  all  support  these  standard 
back-up  functions.  Some  MUMPS  operating  systems  support  journaling  specified 
global  files  to  disk  or  magnetic  tape  as  an  additional  back-up  method;  however, 
this  process  is  not  recommended  because  the  mechanism  has  not  been  adequately 
tested  and  this  process  requires  significant  system  resources  and  operator  time. 


Efficiency  of  Source  Program  Code 

NOHIMS  has  been  written  to  minimize  the  amount  of  system  memory  required  to 
operate  and  to  make  operation  as  efficient  as  possible  within  the  parameters  of 
the  file  structures.  In  the  industrial  component  of  NOHIMS,  variables  that  are 
referenced  frequently  are  stored  in  local  memory  to  decrease  the  amount  of  disk 
access  required.  The  use  of  indirection  has  been  kept  to  a  minimum.  Global 
files  are  arranged  to  minimize  searching  since  routines  access  data  files 
directly  through  node  references  rather  than  through  sequential  searches. 


Because  COSTAR  (the  basis  for  the  medical  component  of  NOHIMS)  was  written 
as  a  multi-purpose  package  to  be  used  in  a  wide  variety  of  settings,  some  trade¬ 
offs  in  efficiency  were  accepted  in  order  to  maximize  flexibility  and  minimize 
programmer  inervention.  Thus,  COSTAR  relies  fairly  heavily  on  indirection.  For 
example,  indirection  is  used  to  reference  a  patient's  file  in  order  to  avoid 
multiple  index  levels  in  the  patient  record  globals  and  to  increase  disk  storage 
efficiency.  On  the  other  hand,  COSTAR  has  built-in  efficencies  within  file 
indices  to  keep  sequential  searches  to  a  minimum.  Access  into  records  has  been 
carefully  minimized  both  in  the  look-up  and  reporting  functions  by  mechanisms 
such  as  the  fast  visit  index.  Within  the  patient  files,  internal  lists  point  to 
the  most  frequently  retrieved  data  items.  As  in  the  industrial  component, 
variables  that  are  referenced  often  are  stored  in  local  memory  to  decrease  disk 
access. 


Hardware  Independence 

NOHIMS  will  run  on  any  hardware  that  can  support  multi-user  ANSI  Standard 
MUMPS  and  that  has  the  minimum  hard  disk  requirements  for  the  particular 
application.  MUMPS  systems  exist  for  DEC,  Data  General,  Harris,  Plessey,  Prime, 
Tandem,  and  IBM  minicomputers.  MUMPS  systems  also  exist  for  several 
microcomputers  such  as  Tandy,  IBM,  Convergent  Technologies  (Burroughs/NCR 
equivalents),  COMPAQ,  Motorola,  and  Olivetti.  The  industrial  component  of 
NOHIMS  requires  a  minimum  of  a  10K  partition  in  system  memory  and  5  megabytes  of 
hard  disk  storage  in  addition  to  the  basic  memory  requirements  for  MUMPS.  The 
medical  component  requires  a  minimum  of  a  6K  partition  of  system  memory,  4-8 
megabytes  of  hard  disk  storage  (dependent  on  the  version  of  MUMPS  used)  for  the 
COSTAR  routines  and  directories,  and  an  additional  10-40  megabytes  of  disk 
storage  for  patient  record  storage  (COSTAR  uses  approximately  1,000-2,000  bytes 
per  encounter  stored). 

NOHIMS  can  accommodate  a  variety  of  terminal/cursor  types  including  any 
hardcopy  device,  Infoton  standard  or  Vistar  with  number  pad,  dumb  terminals,  and 
smart  terminals.  NOHIMS,  at  this  point  in  time,  does  not  support  terminals  with 
split  screen  features. 


Maintainability 

At  the  present  time,  virtually  no  software  support  is  needed  for  the 
industrial  component  of  NOHIMS.  The  internal  integrity  checks  in  the  system 
mean  that  NOHIMS  is  reliable  and  operationally  error-free.  The  industrial 
component  does  require  system  support  by  a  system  manager  to  ensure  that  the 
tables  and  directories  are  kept  up-to-date.  The  medical  component  of  NOHIMS 
requires  minimal  ongoing  software  support  to  fix  software  problems.  During  the 
first  months  of  installation  and  operation  of  the  medical  component,  outside 
software  support  was  required  frequently,  but  now  the  medical  component  operates 
relatively  free  of  software  support.  Unless  changes  or  additions  are  made  to 
the  data  collection  forms,  minimal  system  support  for  the  tables  and  directories 
is  required.  A  system  manager  should  review  the  error  logs  and  start  and  stop 
monitor  on  an  at  least  daily  basis  because  the  error  logs  may  indicate  pending 
system  problems.  IE  new  versions  of  existing  forms  or  additional  encounter 
forms  are  developed,  the  system  support  (forms  design,  directory  work,  etc.)  to 
implement  these  forms  is  expected  to  be  substantial.  In  addition,  NOHIMS  will 
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require  long-term  file  maintenance,  record  archiving  when  disks  become  full,  and 
decisions  about  file-disk  set-ups.  The  frequency  of  these  functions  will  depend 
on  the  size  of  the  application  and  hardware  constraints. 


Summary 

NOHIMS  provides  the  functions  necessary  to  input,  store,  edit,  retrieve, 
and  display  both  various  workplace  monitoring  data  and  selected  occupational 
health  data.  The  industrial  component  of  NOHIMS  needs  to  be  augmented  to 
retrieve  historical  data.  The  medical  component  does  not  presently  handle  data 
from  injury  and  illness  care;  however,  the  Naval  Health  Research  Center  is 
developing  this  capability.  Both  components  of  NOHIMS  have  limited  capabilities 
for  storing  and  processing  occupational  health  program  management  data.  NOHIMS 
can  provide  summaries  of  various  medical  and  exposure  data,  although  there  are 
only  a  few  links  between  the  two  databases. 

NOHIMS  is  considered  to  be  a  very  reliable  system.  The  only  known  bug  is 
in  the  COSTAR  Report  Generator  when  there  is  more  than  one  encounter  on  the  same 
day.  This  bug  is  not  a  result  of  NOHIMS,  but  is  a  design  flaw  in  public  domain 
COSTAR.  The  user  cannot  intentionally  or  unintentionally  corrupt  the  database. 
The  system  manager  or  someone  who  enters  the  system  via  the  programmer's  access 
code  could  potentially  corrupt  the  routines  and/or  database.  NOHIMS  can 
resolve  extraneous  or  ambiguous  input.  The  validity  of  data  input  is  checked  to 
some  degree.  Both  the  medical  and  industrial  components  have  system  functions 
that  aid  in  recovering  data  if  an  error  or  system  crash  occurs.  The  operating 
systems  that  support  MUMPS  support  the  procedures  necessary  to  back-up  the 
entire  NOHIMS  system  on  disk. 

NOHIMS  has  been  written  to  minimize  the  amount  of  memory  required  and 
to  make  operation  as  efficient  as  possible  without  jeopardizing  the  flexibility 
of  NOHIMS  while  minimizing  necessary  programmer  intervention. 

NOHIMS  will  run  on  any  hardware  that  can  support  ANSI  Standard  MUMPS  and 
has  the  minimum  hard  disk  requirement  for  the  particular  application.  NOHIMS 
can  also  accommodate  a  variety  of  terminal/cursor  types. 

Very  little  software  support  is  required  to  maintain  NOHIMS  because  both 
NOHIMS  components  run  relatively  error  free  once  they  have  been  installed  and 
are  operational.  Unless  changes  or  additions  are  made  to  the  data  collection 
forms,  minimal  system  support  is  needed.  If  new  versions  of  existing  forms  or 
additional  forms  are  required,  the  system  support  necessary  to  implement  these 
forms  will  be  substantial.  Long-term  system  support,  such  as  file  maintenance, 
will  also  be  required.  The  amount  of  long-term  system  support  needed  will 
depend  on  the  size  of  the  application  and  hardware  constraints. 


ASSESSMENT  OF  OPERATIONAL  CHARACTERISTICS 

To  evaluate  the  operational  characteristics  of  NOHIMS,  we  have  described 
NOHIMS'  capabilities  with  regard  to  its  user  friendly  features  such  as  option 
menus,  presentation  of  operational  characteristics,  on-line  assistance 
functions,  error  diagnostics  and  other  debugging  aids,  and  database  manager 


utilities;  data  manipulation  tasks;  and  information  retrieval  capabilities, 
including  standard  report  procedures,  ad  hoc  report  procedures,  and  query 
response  time.  In  addition,  we  interviewed  the  NOHIMS  users  to  determine  their 
assessment  of  the  user  friendliness  of  NOHIMS  and  their  evaluation  of  the 
information  retrieval  capabilities  of  NOHIMS.  Each  of  these  five  topics  is 
covered  in  a  subsection  below. 


Description  of  User  Friendly  Features 


NOHIMS  has  a  variety  of  features  that  make  it  very  user  friendly.  NOHIMS 
is  a  "menu  driven"  system  at  all  option  selection  levels.  The  system  presents 
its  operational  capabilities  to  the  user  in  generally  clear  and  helpful  ways. 
It  has  extensive  on-line  assistance  functions  as  well  as  various  error 
diagnostic  features  and  debugging  aids.  In  addition,  four  manuals  and  several 
job  aids  have  been  developed  as  a  back-up  reference  for  the  user.  NOHIMS  does 
not  have  database  manager  utilities  as  they  are  traditionally  defined.  These 
functions  can  be  approximated  through  other  standard  NOHIMS  options. 


Option  Menus 


NOHIMS  works  from  an  option  menu  at  all  selection  levels.  At  each  point  in 
the  option  selection  process,  the  user  selects  the  next  option  level  by  entering 
the  minimum  number  of  letters  of  the  option  to  uniquely  identify  it.  Whenever 
requested  by  the  user,  NOHIMS  will  display  those  options  that  are  accessible 
from  that  point  in  the  selection  process  and  that  are  accessible  to  that  person 
on  the  device  in  use.  The  option  menu  is  triggered  by  entering  a  "?"  at  the 
option  selection  prompt.  Thus,  the  option  menus  are  generally  transparent  to 
the  user  unless  they  are  deliberately  called  by  the  user.  In  the  medical 
component,  the  option  levels  take  the  user  down  branches.  You  may  not  go 
directly  to  an  option  in  another  branch.  You  must  first  back  out  of  that  branch 
and  go  down  another  branch.  In  the  industrial  component,  NOHIMS  allows  the  user 
to  jump  to  other  modules  from  within  a  module  when  it  is  appropriate. 


Presentation  of  Operational  Characteristics 


Option  Displays.  NOHIMS  present  system  options  and  prompts  in  a  clear  and 
helpful  manner.  As  mentioned  above,  NOHIMS  is  a  menu  driven  system  at  all 
option  levels.  At  each  option  selection  point,  NOHIMS  can  display  all  of  the 
options  available  to  the  user  on  the  particular  device  in  use.  Some  of  the 
system  prompts  actually  contain  the  options  within  the  text  of  the  prompt  such 
as  the  File,  Edit,  or  Ignore  prompt.  In  the  medical  component  the  option  menus 
are  almost  always  presented  in  a  list  that  proceeds  down  the  screen.  The 
industrial  component  uses  lists  down  the  screen  as  well  as  lists  in  a  line  of 
text  across  the  screen. 


The  system  prompts  in  both  components  are  descriptive  without  being  too 
wordy.  They  are  generally  easy  to  understand,  although  a  few  (for  example,  the 
New  Patient  Named  prompt  in  the  medical  component)  have  been  reported  to  be 
cryptic  to  the  user  until  he/she  is  familiar  with  the  system.  In  defining  the 
system  prompts,  the  NOHIMS  developers  tried  to  strike  a  balance  between  user 
friendliness  for  new  users  and  speed  and  simplicity  for  experienced  users. 


Report  Displays.  The  NOHIMS  designers  have  endeavored  to  make  report 
displays  easily  readable  and  understandable.  In  the  medical  component,  the 
display  format  for  the  Encounter  Report  is  fixed.  The  content  of  the  Encounter 
Report  is  self-explanatory.  Data  are  organized  by  directory  code  division.  The 
format  of  the  Status  Report  is  also  fixed.  The  format  for  the  Patient  Summary 
may  be  defined  within  certain  constraints  by  the  system  manager  through  the 
System  Maintenance  module.  The  data  in  the  Status  Report  and  the  Patient 
Summary  are  also  ordered  by  directory  code  division.  The  selection  criteria  for 
inclusion  of  textual  comments  and  historical  detail  in  these  reports  is  not 
obvious  to  the  user,  however.  The  criteria  for  the  inclusion  of  these  data  in 
the  reports  are  explained  in  the  NOHIMS  medical  component  operational  and  system 
manager  manuals.  The  display  format  of  the  Flowcharts,  the  COSTAR  Report 
Generator  reports,  and  the  Interactive  Flowcharts  may  be  defined  by  the 
individual  user,  although  again,  they  must  be  within  the  constraints  of  each 
function.  The  displays  of  the  flowcharts  and  the  COSTAR  Report  Generator 
reports  are  clear  once  the  user  has  understood  how  the  report  specifications  are 
defined.  Detailed  instructions  on  the  use  of  these  three  functions  are 
contained  in  the  system  documentation  to  aid  the  user  in  interpreting  these 
reports. 

In  the  industrial  component,  the  display  formats  for  the  reports  are  fixed 
to  the  user.  For  example,  the  interactive  query  function  simply  progressively 
indents  each  unique  data  group  much  like  an  outline.  This  feature  allows  the 
query  function  to  be  a  more  simple,  efficient,  easy-to-use  retrieval  system 
rather  than  a  cumbersome  report  formatting  operation.  All  of  the  reports 
produced  by  the  industrial  component  use  titles  and  headlines  to  clarify  data 
contained  in  the  reports. 

System  Messages.  NOHIMS  uses  system  messages  to  indicate  to  the  user  how 
an  entry  has  been  interpreted.  As  a  rule,  these  messages  tend  to  be  abbreviated 
in  order  to  communicate  a  message  quickly  and  easily.  For  example,  an 
unacceptable  laboratory  result  in  the  medical  component  is  indicated  by  a  "???" 
response  and  on-line  filing  is  indicated  by  three  dots,  Other  system 

messages  indicate  program  errors,  invalid  codes,  and  invalid  formats  of  entries. 
NOHIMS  also  uses  system  messages  to  alert  the  user  to  wait  while  data  are  being 
processed. 


On-Line  Assistance  Functions 

Text.  any  industrial  component  prompt,  the  user  is  allowed  to 
enter  a  ?  character  when  in  doubt  as  to  the  proper  response  or  action,  or  if 
the  necessary  response  is  unknown.  NOHIMS  will  then  provide  the  user  with 
either  an  explanation  of  the  expected  response  and/or  a  list  of  applicable 
responses  from  which  the  user  may  select  the  appropriate  response.  The  help 
text  and/or  examples  that  are  provided  are  specific  to  NOHIMS  and  are  usually 
specific  to  the  application  environment.  For  example,  if  the  user  is  required 
to  enter  a  department  code,  NOHIMS  will  list  the  departments  defined  in  that 
application  environment  and  their  respective  codes.  The  help  text  can  be 
changed  without  programmer  intervention  by  accessing  the  System  Table  Edit 
option  in  the  Maintenance  module  of  the  industrial  component. 
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As  in  the  industrial  component,  the  user  may  also  use  the  "?"  response  to 
obtain  on-line  help  in  the  medical  component.  If  the  "?"  character  is  entered, 
NOHIMS  will  respond  with  an  explanation,  a  list  of  applicable  responses,  and/or 
a  sample  response,  as  appropriate.  The  help  text  will  also  indicate  whether  the 
user  may  obtain  further  detail  by  entering  an  "AL"  at  the  system  prompt. 
Generally ,  the  "AL"  presents  the  user  with  lists  that  are  maintained  in  the 
system,  such  as  all  possible  sites  of  encounters  or  types  of  encounters.  The 
question  mark  help  text  for  system  prompts  and  certain  laboratory  tests  results 
entry  sequences  are  hard-coded  in  the  software  and  cannot  be  altered  without  a 
programmer's  intervention.  Help  text  for  entering  results  data  for 
administrative,  physical  findings,  or  most  laboratory  tests  codes  is  defined  and 
maintained  through  the  System  Maintenance  module  in  the  medical  component.  The 
contracted  NOHIMS  developers  have  modified  the  public  domain  help  text  to  make 
it  specific  to  the  needs  of  the  Occupational  Health  Unit,  North  Island.  These 
responses  can  be  easily  altered  through  the  System  Maintenance  module. 

Supporting  Documentation  and  Job  Aids.  Both  the  medical  and  industrial 
components  of  NOHIMS  have  extensive  operations  and  system  maintenance  manuals 
written  specifically  for  NOHIMS  to  support  and  augment  the  system's  on-line 
assistance  functions.  These  are  the  NOHIMS  Users'  Reference  Manual  and  the 
NOHIMS  System  Manager's  Manual  for  the  medical  component  and  the  NOHIMS  User's 
Guide  and  the  NOHIMS  OHS  System  Maintenance  Manual  for  the  industrial  component. 
These  manuals  explain  the  purpose  of  each  module  of  the  system  and  the  options 
under  each  module.  In  addition,  the  documentation  for  the  medical  component 
contains  examples  of  typical  data  entry  sequences  and  job  aids  that  contain 
lists  of  patient  items  or  codes  that  may  be  referenced  during  data  entry.  The 
job  aids  include  Possible  Patient  Items  in  Registration  and  Data  Items  Specified 
as  Other  (Hazardous  Agent  Surveillance,  Laboratory  Tests,  Radiology,  Problem 
Codes,  and  ICD-9-CM  Diagnoses).  The  manual  also  contains  three  clear  plastic 
overlays  to  be  used  in  entering  data  from  the  Asbestos  Medical  Surveillance 
Program  and  the  Hearing  Conservation  Program.  A  comparison  of  the  operation  of 
NOHIMS  and  the  documentation  was  made  as  part  of  this  test  and  evaluation.  The 
results  of  this  study  may  be  found  in  the  Operational  Testing  of  NOHIMS  section 
of  this  report. 

Text  Editors.  Both  the  industrial  and  medical  components  of  NOHIMS  have 
simple  text  editors  to  aid  in  the  entry  or  modification  of  textual  entries.  The 
editor  automatically  controls  all  line  length  restrictions  by  word  wrapping  and 
allows  simple  text  editing  tasks  such  as  insertion,  deletion,  and  replacement. 

Default  Values.  NOHIMS  uses  default  values  to  minimize  data  entry 
keystrokes.  Each  prompt  for  user  input  in  NOHIMS  ends  with  a  caret  symbol  (>) 
or  a  triple  caret  symbol  (»>)  to  indicate  that  NOHIMS  is  awaiting  an  entry.  In 
many  cases,  such  as  during  an  edit  sequence,  the  value  for  the  prompt  is  already 
known  or  there  is  an  expected  response.  If  the  entry  value  is  known  or 
expected,  NOHIMS  presents  the  value  within  carets  to  give  the  user  the 
opportunity  to  accept  this  default  value  by  simply  pressing  the  Return  key,  to 
erase  the  default  value  by  entering  a  backslash  character  (\)  or  a  minus 
character  (-),  or  to  enter  a  new  value. 


"  ►  >  *  *  '  -  ‘  »  '«"*■'  « 
V  \  \  V" 


The  industrial  component  of  NOHIMS  has  the  capability  of  intercepting  error 
interrupts  during  routine  operation.  Whether  due  to  hardware  or  software 
errors,  NOHIMS  aborts  the  ongoing  task  when  an  error  is  detected  and  logs  the 
error  and  the  contents  of  memory  at  the  time  of  the  error  in  an  error  file. 

This  file  can  be  reviewed  by  the  system  manager  and/or  system  programmer  through 
the  Error  Reports  option  of  the  Maintenance  module.  The  error  log  is  maintained 
indefinitely  until  a  system  manager  deletes  old  or  corrected  errors  using  the 
Kill  option  in  the  Error  Reports  function. 

The  medical  component  of  NOHIMS  has  a  function  that  is  similar  to  the  error 
report  of  the  industrial  component.  When  an  error  occurs,  the  medical 
component  logs  the  program  location  of  the  error  or  the  type  of  hardware  error, 
a  descriptive  message  regarding  the  error,  if  any,  and  the  memory  contents  at 
the  time  of  the  error.  These  data  are  stored  in  the  "'ERR  global  by  sequential 
error  number  for  the  date  of  the  error.  Not  all  errors  detected  by  this 
function  cause  the  task  to  abort.  Some  errors  are  noted  to  flag  potential 
filing  problems.  The  error  log  may  be  reviewed  by  the  system  manager  or 
programmer  via  the  Error  Log  suboption  of  the  Transaction  Control  option  in  the 
System  Maintenance  module.  By  entering  an  "AS"  at  the  Symbol  prompt,  the  system 
status  at  the  time  of  the  error  can  be  recreated  to  aid  in  debugging  the  error. 
The  errors  logged  in  the  error  file  can  only  be  deleted  by  programmer's 
intervention.  In  addition,  the  medical  component  has  a  Software  Performance 
Report  option  that  aids  in  system  testing  and  debugging.  In  this  option,  a 
system  user  can  document  program  errors  or  system  bugs  for  later  review  by  the 
system  manager.  This  option  also  has  a  test  function  that  allows  features  of 
the  system  to  be  tested  while  the  testing  process  is  being  automatically  logged. 
This  option  is  not  used  much  at  other  COSTAR  installation  sites,  however.  The 
Mailbox  module  of  the  medical  component,  an  internal  message  storage  and 
retrieval  system,  may  also  be  used  by  system  users  to  manually  log  program 
errors  for  the  system  manager. 


Database  Manager  Utilities 


NOHIMS  does  not  have  any  database  manager  utilities  per  se.  All  data 
retrieval  is  performed  via  the  various  report  functions  found  in  the  Display 
Medical  Data,  Print  Medical  Data,  and  COSTAR  Report  Generator  modules  of  the 
medical  component  or  found  in  the  Query/Report  module  and  the  Display  options  of 
the  Hazard  Data,  Survey  Data,  Agency  Data,  Environment  Data,  and  Personnel  Data 
modules  of  the  industrial  component.  Using  these  functions,  all  current  data 
items  can  be  retrieved  in  some  form.  In  addition,  the  medical  component  will 
retrieve  historical  data  items. 

The  data  manipulation  capabilities  of  NOHIMS  are  limited.  Neither 
component  supports  the  creation  of  new  variables  based  on  variables  already  in 
the  system  such  as  ratios  or  percentage  ratings.  Patients/workers  cannot  be 
recategorized  on  the  basis  of  selected  criteria  and  actual  data  files  may  net  be 
sorted  or  reordered  permanently.  However,  the  intent  of  these  functions  can  be 
approximated  by  selecting  subsets  of  patients/workers  for  description  or  study 
through  the  normal  data  retrieval  functions. 


Summary 


NOHIMS  has  a  variety  of  features  that  make  it  very  user  friendly.  NOHIMS 
is  a  "menu  driven"  system  at  all  option  selection  levels.  The  system  presents 
system  options  and  prompts  in  a  clear  and  helpful  mannner.  The  prompts  are 
descriptive  without  being  too  wordy.  In  defining  the  system  prompts,  the  NOHIMS 
developers  tried  to  strike  a  balance  between  user  friendliness  for  new  users  and 
speed  and  simplicity  for  experienced  users.  The  NOHIMS  designers  have 
endeavored  to  make  report  displays  easily  readable  and  understandable.  NOHIMS 
uses  system  messages  to  indicate  to  the  user  how  an  entry  has  been  interpreted. 
The  system  has  extensive  on-line  assistance  functions  including  help  text  at  all 
prompts,  simple  to  use  text  editors  for  textual  entries,  and  default  values  to 
aid  data  entry.  In  addition,  four  operational  manuals  and  several  job  aids  were 
developed  specifically  for  NOHIMS  as  a  back-up  reference  for  the  user.  NOHIMS 
has  error  diagnostic  features  and  debugging  aids.  These  include  error 
intercepts,  error  reports,  and  a  feature  in  the  medical  component  that  recreates 
the  system  status  at  the  time  of  a  problem  to  aid  in  debugging  the  error.  The 
medical  component  has  a  Software  Performance  Report  option  that  allows  the 
system  users  to  document  program  errors  or  system  bugs  for  later  review  by  the 
system  manager.  This  option  also  has  a  test  function  that  allows  features  of 
the  system  to  be  tested  while  the  testing  process  is  being  automatically  logged. 
NOHIMS  does  not  ha*  e  database  manager  utilities  as  they  are  traditionally 
defined;  however,  these  functions  can  be  approximated  through  other  standard 
NOHIMS  options. 


Evaluation  of  User  Friendliness 

We  asked  the  people  who  were  most  likely  to  have  hands-on  experience  with 
NOHIMS,  namely,  the  medical  care  providers,  industrial  hygienists,  data  entry 
clerks,  and  system  managers  to  assess  the  user  friendliness  of  NOHIMS.  We 
interviewed  six  medical  care  providers,  five  industrial  hygienists,  two  data 
entry  clerks,  and  two  system  managers.  The  questions  on  user  friendliness 
covered  the  ease  of  learning  NOHIMS,  the  users'  confidence  level  in  using 
NOHIMS,  how  easy  NOHIMS  is  to  operate  compared  to  other  systems  they  have  used, 
and  overall  user  friendliness.  In  addition,  we  asked  the  users  to  rate  each  of 
eleven  features  as  to  how  helpful  they  were  in  operating  the  system.  Finally, 
we  solicited  suggestions  that  the  interviewee  thought  would  improve  the  user 
friendliness  of  NOHIMS.  The  exact  wording  of  the  questions  hat  we  asked  may  be 
found  in  Appendix  A,  Component  10. 

Table  10  shows  how  the  users  rated  NOHIMS  on  ease  of  learning.  Three  of 
the  medical  providers  (the  physicians)  had  not  had  hands-on  experience  with 
NOHIMS.  Of  chose  having  experience  with  NOHIMS,  84  percent  thought  that 
learning  NOHIMS  was  somewhat  easy  or  very  easy.  An  industrial  hygienist  rated 
NOHIMS  as  somewhat  difficult  to  learn.  One  of  the  system  managers  said  that  the 
ease  of  learning  depended  on  the  part  of  the  system  that  he  had  learned;  the 
Interactive  Query  function  in  the  industrial  component  and  the  COSTAR  Report 
Generator  in  the  medical  component  were  more  difficult  to  learn  than  the  rest  of 
NOHIMS.  The  Bremerton  users  generally  rated  NOHIMS  as  less  easy  to  learn  than 
the  users  in  San  Piego.  They  commented  that  they  did  not  receive  training  and 
very  little  system  documentation  was  available.  The  person  who  rated  NOHIMS  as 
somewhat  difficult  to  learn  stated  that  now  it  is  very  easy  to  use. 
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TABLE  10 

Ease  of  Learning  NOHIMS 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

Data  Entry 
Clerks 

System 

Managers 

TOTAL 

%  of 

Total  With 
Experience 

Very  easy 

2 

2 

1 

0 

5 

42 

Somewhat  easy 

1 

2 

1 

1 

5 

42 

Somewhat 

difficult 

0 

1 

0 

0 

1 

8 

Very 

difficult 

0 

0 

0 

0 

0 

0 

Other 

0 

0 

0 

1 

1 

8 

TOTAL  WITH 
EXPERIENCE 

No  hands-on 
experience 

TOTAL  INTERVIEWED 


3 

6 


0 

5 


0 

2 


0 

2 


12 

3 

13 


100 
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In  Table  11  we  see  that  84  percent  of  those  with  hands-on  experience  with 
NOHIMS  now  feel  very  confident  or  somewhat  confident  with  using  NOHIMS,  although 
more  of  these  respondents  feel  somewhat  confident  than  very  confident.  Again, 
one  industrial  hygienist  gave  a  rating  of  somewhat  unsure  of  using  NOHIMS, 
although  this  is  not  the  same  person  that  said  NOHIMS  was  somewhat  difficult  to 
learn.  The  system  manager  who  gave  a  mixed  rating  to  NOHIMS  on  ease  of  learning 
stated  that  he  felt  confident  about  most  of  the  system,  but  somewhat  unsure 
about  the  Interactive  Query  and  COSTAR  Report  Generator  functions.  He  felt  that 
confidence  in  these  areas  would  come  with  experience,  however. 

Seven  out  of  twelve  of  those  with  hands-on  experience  with  NOHIMS  had  had 
experience  with  other  information  systems.  Of  these  seven,  five  thought  that 
NOHIMS  was  easier  to  use.  One  person  thought  that  NOHIMS  was  somewhat  easier, 
and  one  thought  there  was  no  difference  in  ease  of  use  (see  Table  12). 

Table  13  contains  the  users'  ratings  of  each  of  eleven  NOHIMS  features  that 
are  designed  to  aid  the  user  in  learning  and  operating  the  system.  The  last 
column  in  the  table  is  the  percentage  of  the  people  with  hands-on  experience  who 
rated  NOHIMS  as  very  helpful.  Everyone  with  experience  with  the  feature  rated 
the  screen  displays,  system  prompts/menus,  environment  look-up,  hazardous  agent 
look-up,  and  directory  item  look-up  as  very  helpful.  The  two  features  with  the 
poorest  helpfulness  ratings  were  survey  data  look-up  and  system  messages  with 
ratings  of  75  percent  and  60  percent  of  users,  respectively.  The  respondents 
did  not  make  any  specific  criticisms  about  the  system  messages.  However,  users 
commented  that  the  survey  data  look-up  function  needed  a  way  to  narrow  the 
search.  Other  anecdotal  comments  on  the  user  friendly  features  included  "the 
screen  displays  slow  down  the  entry  process  once  you're  familiar  with  the 
system,"  "the  intent  of  system  prompts/menus  is  not  always  clear,"  "create/edit 

survey  is  very  awkward. . .doesn't  flow _ can't  correct  errors. .. [and]  is  rigid," 

and  "some  things  don't  work  smoothly  with  material  inventory  items  (product 
names)."  It  should  be  noted  that  none  of  the  user  friendly  features  received 
even  a  single  rating  of  not  helpful. 

Ninety-one  percent  of  those  who  rated  the  overall  user  friendliness  of 
NOHIMS  gave  NOHIMS  a  rating  of  very  user  friendly  (see  Table  14).  The  only 
person  who  gave  NOHIMS  an  overall  rating  of  somewhat  friendly  was  one  of  the 
system  managers.  He  felt  that  "new  people  find  it  unfriendly  at  first  approach" 
and  that  "doctors  seem  intimidated  [by  NOHIMS]."  One  industrial  hygienist 
summed  up  her  thoughts  about  the  user  friendliness  of  NOHIMS  by  saying  that 
"[NOHIMS]  gives  you  a  chance." 

The  interviewees  mentioned  a  number  of  ways  in  which  the  user  friendliness 
of  NOHIMS  could  be  improved;  however,  none  of  these  ways  was  mentioned  by  more 
than  one  person.  These  suggestions  are  listed  in  Table  15.  Several  of  the 
suggestions  were  made  with  the  thought  that  although  the  feature  was  already 
helpful,  it  could  be  made  even  more  helpful.  The  ideas  included  improving  the 
help  text  and  system  prompts,  adding  a  type  ahead  capability,  improving  look-ups 
in  the  materials  inventory  by  adding  more  products  to  the  hazardous  agent  table, 
expanding  NOHIMS  to  do  functions  other  than  occupational  health,  improving  list 
code  entry,  putting  normal  and  abnormal  boxes  on  the  same  line  on  the  Physical 
Examination  form,  adding  the  ability  to  repeat  survey  data  for  multiple  agents, 
and  creating  a  text  editor  for  industrial  data.  An  industrial  hygienist  at 
Bremerton  suggested  adding  the  risk  assessment  code  which  combines  the  elements 
of  hazard  severity  and  mishap  probability  to  the  survey  data  collection  forms 


TABLE  11 

Confidence  in  Use  of  NOHIMS 
(Number  who  mentioned  rating) 


Very  confident 

Somewhat 

confident 

Somewhat 

unsure 

Very  unsure 

Other 


Medical 

Care 

Providers 

Industrial 

Hygienists 

Data  Entry 
Clerks 

System 

Managers 

TOTAL 

%  of 
Total 

Interviewed 

1 

1 

1 

1 

4 

34 

2 

3 

1 

0 

6 

50 

0 

1 

0 

0 

1 

8 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

1 

8 

TABLE  12 

Ease  of  Use  of  NOHIMS  Compared  to  Other  Systems 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

Data  Entry 
Clerks 

System 

Managers 

TOTAL 

%  of 

Total  Who 
Used  Other 
Systems 

Easier 

0 

3 

1 

1 

5 

72 

Somewhat  easier 

0 

0 

1 

0 

1 

14 

No  difference 

1 

0 

0 

0 

1 

14 

Somewhat  more 
difficult 

0 

0 

0 

0 

0 

0 

More  difficult 

0 

0 

0 

0 

0 

0 

TOTAL  WHO  USED 
OTHER  SYSTEMS 

1 

3 

2 

1 

7 

100 

Not  used  other 

2 

2 

0 

1 

5 

TOTAL  INTERVIEWED 

3 

5 

2 

2 

12 

TABLE  13 

Helpfulness  of  NOHIMS  Features 
(Number  who  mentioned  rating) 


%  Very 

Very  Somewhat  Not  Helpful 

Helpful  Helpful _ Helpful _ TOTAL  of  Total* 


Screen  displays 

12 

0 

0 

12 

100 

System  promts/ 
menus 

11 

0 

0 

11 

100 

System  messages 

6 

A 

0 

10 

60 

Help  text/ 

assistance  functions 

10 

2 

0 

12 

83 

Report  formats 

9 

1 

0 

10 

90 

Techniques  for 
looking  up  an 
individual 

9 

1 

0 

10 

90 

Agency  unit 
look-up 

5 

1 

0 

6 

83 

Environment 

look-up 

8 

0 

0 

8 

100 

Survey  data 
look-up 

6 

2 

0 

8 

75 

Hazardous  agent 
look-up 

7 

0 

0 

7 

100 

Directory  item 
look-up 

A 

0 

0 

A 

100 

*  Percentage  of  those  people  answering  the  question  who  stated  that  the  NOHIMS 
feature  was  very  helpful.  The  total  number  answering  he  question  varies 
because  some  people  could  not  comment  on  some  features. 


TABLE  14 

Overall  User  Friendliness  of  NOHIMS 
(Number  who  mentioned  rating) 


Medical  ^ 

Care  Industrial  Data  Entry  System  Total  Who 

Providers  Hygienists _ Clerks  Managers  TOTAL  Answered 


Very  user 
friendly 

Somewhat  user 
friendly 

Somewhat  user 
unfriendly 

Very  user 
unfriendly 


TOTAL  WHO  ANSWERED 


No  Comment 


TOTAL  INTERVIEWED 


TABLE  15 

Suggestions  for  Improving  User  Friendliness 
(All  mentioned  once) 


Improve  help  text 

Improve  prompts 

Add  type  ahead  capability 

Add  more  products  to  the  hazardous  agent  table  so 
that  an  agent  may  be  looked  up  by  both  the  product 
name  and  the  component  hazardous  agents  to  make 
hazardous  agent  look-ups  easier 

Expand  to  do  functions  other  than  occupational 
health 

Improve  list  code  entry  (to  be  able  to  back  up) 

Put  normal  and  abnormal  boxes  on  same  line  of  the 
Physical  Examination  form 

Add  ability  to  repeat  survey  data  for  multiple 
agents 

Create  text  editor  for  industrial  data 

Add  risk  assessment  code  for  hazards  to  survey  data 
entry  [Requested  by  Bremerton;  new  forms  put  into 
use  at  Bremerton  in  April  1986  contained  the  risk 
assessment  code  as  requested.  1 


and  survey  data  entry.  In  April  1986  the  Bremerton  industrial  hygienists 
reported  receiving  new  survey  data  collection  forms  that  contained  the  risk 
assessment  code  as  was  desired. 


Summary 

The  system  users  with  hands-on  experience  generally  thought  that  NOHIMS  was 
at  least  somewhat  easy  to  learn  and  is  easier  to  use  than  other  systems. 
Eighty-four  percent  of  those  who  rated  the  ease  of  learning  NOHIMS  thought  that 
NOHIMS  was  at  least  somewhat  easy  to  learn;  72  percent  of  those  who  had  used 
other  systems  thought  that  NOHIMS  was  easier  to  use  than  other  systems.  Almost 
all  of  the  interviewees  (84%)  were  somewhat  confident  or  very  confident  in  using 
the  system.  The  system  has  several  features  that  users  rated  as  being  very 
helpful  in  using  the  system.  The  features  with  the  highest  helpfulness  ratings 
included  screen  displays,  system  prompts/menus,  environment  look-up,  hazardous 
agent  look-up,  and  directory  item  look-up;  everyone  who  had  used  these  features 
thought  that  they  were  very  helpful.  Overall,  91  percent  of  those  respondents 
with  hands-on  experience  thought  that  NOHIMS  was  very  user  friendly. 


Description  of  Data  Manipulation  Tasks 

The  following  subsection  describes  aspects  of  the  data  manipulation  tasks 
of  NOHIMS.  Topics  covered  include  average  entry  time  per  input  form,  edit 
capabilities,  search-in-context  capability,  general  filing  procedures,  and 
downloading  to  magnetic  tape. 


Average  Entry  Time  Per  Input  Form 

The  data  entry  clerk  for  the  medical  component  of  NOHIMS  at  the 
Occupational  Health  Unit,  North  Island,  San  Diego,  California  estimated  that  he 
can  enter  between  30  and  40  complete  medical  encounters  per  day  of  data  entry 
(12-16  minutes  per  encounter).  Complete  data  entry  includes  registering  the 
patients,  entering  all  encounter  data,  and  entering  all  laboratory  results  data. 
The  time  required  to  input  the  data  from  an  encounter  varies  greatly.  The 
length  of  time  is  dependent  on  the  response  time  of  the  system  and  the  amount  of 
data  for  the  encounter.  Approximately  one-third  of  the  medical  encounters  have 
only  a  Pulmonary  Function  Test  or  Audiogram  and  no  other  laboratory  tests.  When 
this  is  the  case,  data  entry  goes  much  faster. 

The  data  entry  clerk  at  Bremerton,  Washington  who  enters  industrial  data 
was  reported  to  enter  8  to  10  Industrial  Hygiene  Survey  forms  per  hour  (6-7.5 
minutes  per  survey  form).  If  the  survey  required  the  entry  of  Occupational 
Hazard  Data  Sheets  and  a  Material  Inventory,  the  number  of  surveys  entered  per 
hour  dropped  to  3  to  4  (15-20  minutes  per  survey).  This  data  entry  clerk  was 
reported  to  be  a  skilled  typist,  and  therefore,  very  fast  at  data  entry. 

No  one  person  at  the  Industrial  Hygiene  Division,  San  Diego,  was  tasked 
with  entering  the  survey  data.  The  data  entry  clerk  for  the  medical  component 
reported  doing  some  survey  data  entry.  lie  estimated  that  he  was  entering  two 
complete  surveys  per  hour  (30  minutes  per  survey);  however,  he  did  not  feel  that 
he  had  a  great  deal  of  experience  doing  survey  data  entry.  A  data  entry  clerk 


at  the  Naval  Health  Research  Center,  San  Diego  reported  averaging  two  complete 
survey  forms  per  hour  (30  minutes  per  survey).  The  time  required  was  dependent 
on  the  number  of  Occupational  Hazard  Data  Sheets.  He  estimated  that  each  survey 
had  five  Occupational  Hazard  Data  Sheets  on  the  average. 


Edit  Capabilities 

Both  the  industrial  and  medical  components  have  extensive  edit  capabilities 
to  add,  change,  or  delete  data  from  the  database.  An  edit  function  in  the  five 
data  modules  of  the  industrial  component  is  used  to  edit  or  change  information 
that  has  already  been  entered  in  the  system.  In  the  Agency  Data  module,  the 
Edit  Organization  option  allows  the  user  to  change  names,  acronyms,  or  codes  for 
any  of  the  groups  within  the  organization.  It  also  allows  one  to  add  groups  to 
or  delete  groups  from  the  organization  as  necessary.  Any  alterations  that  are 
made  are  reflected  throughout  the  applicable  levels  of  the  hierarchical 
structure.  The  Edit  Personnel  Data  option  in  the  Personnel  Data  module  allows 
the  user  to  make  any  corrections  that  may  be  necessary  to  an  existing  personnel 
record.  Suboptions  differentiate  between  edit  (correction)  operations  and 
update  operations  on  the  worker's  name.  Editing  of  the  name  replaces  the 
previous  worker  name.  Updating  the  name  causes  a  historical  audit  trail  to  the 
previous  name,  allowing  the  system  to  recognize  the  worker  by  both  the  old  and 
new  name.  In  the  Environment  Data  module,  the  Edit  option  allows  the  user  to 
edit  any  of  the  environments  in  the  system  (e.g.,  change  BLDG  100,  RM  205  from 
"Painting  Area"  to  "Sandblasting  Area").  The  previous  environment  description 
is  archived  in  the  system  along  with  the  date  of  the  edit  or  update.  The  Edit 
Survey  Data  option  in  the  Survey  Data  module  is  used  to  correct  errors  in  survey 
data  that  have  been  entered  in  NOHIMS.  In  the  Hazard  Data  module,  the  Edit 
Hazard  Data  option  allows  the  user  to  edit  or  update  information  that  has  been 
entered  for  a  particular  substance  (e.g.,  the  Navy  may  set  new  exposure  limits 
for  a  substance).  The  edit/update  process  is  also  controlled  by  the  edit/update 
mode  selection  process  when  the  user  logs  onto  the  industrial  component.  If  the 
user  selects  the  edit  process,  an  historical  record  of  changes  is  not  made 
unless  historical  storage  is  mandatory  for  the  data  item  edited  (e.g., 
concentration  measurements  require  historical  storage  of  all  edits).  If  the 
update  mode  is  chosen,  historical  records  of  edits  are  stored  in  the  database. 
The  date  of  the  edit  update  is  also  stored  as  part  of  the  record.  The  general 
format  for  the  edit  function  is  to  direct  the  user  through  each  set  of  prompts 
and  display  the  current  value  within  carets.  The  user  may  either  accept  the 
current  value,  erase  the  value,  or  enter  a  new  value.  Sometimes,  the  user  must 
select  a  separate  suboption  in  order  to  delete  a  data  item. 

In  the  medical  component  of  NOHIMS,  additions,  deletions,  and  edits  to  the 
patient  database  may  be  made  through  the  Patient  Registration/Edit  option  of  the 
Registration  module  and  the  Encounter  Entry,  Medical  Edit,  and  Lab  Results 
options  of  the  Enter  Medical  Data  module.  Both  during  initial  registration  of  a 
patient  and  at  a  later  date,  the  Patient  Registration/Edit  option  can  be  used  to 
edit  any  of  the  registration  data  items.  None  of  the  registration  data  items 
except  the  name  and  social  security  number  is  kept  historically,  that  is,  the 
new  value  replaces  the  previous  value  for  the  given  data  item.  If  either  the 
patient's  name  or  social  security  number  are  modified,  NOHIMS  will  enter  the  new 
value  into  the  patient's  record  and  cross  reference  the  file  to  the  old  value. 
During  encounter  entry,  incorrect  entries  can  be  corrected  by  re-entering  the 
code  and  associated  data  in  the  correct  manner.  The  new  entry  will 
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automatically  take  precedence  over  the  previous  entry.  Data  items  may  be 
flagged  as  an  erroneous  entry  by  typing  an  "E/"  before  the  code.  Once  encounter 
entry  has  been  terminated,  edits  to  the  encounter  record  must  be  made  through 
the  Medical  Edit  option.  After  selecting  to  edit  the  encounter,  data  from  the 
header  of  the  encounter  will  be  displayed.  The  user  may  then  edit  each  header 
data  item  or  accept  the  current  value  for  the  data  item.  In  the  body  of  the 
encounter,  corrected  entries  of  codes  and  associated  data  will  replace  previous 
entries.  The  user  may  also  modify,  delete,  or  add  text  for  a  data  item  that  was 
previously  entered  by  re-entering  the  code  and  selecting  to  edit  the  text.  Data 
items  may  also  be  flagged  as  erroneous  input  with  the  "E/"  entry.  Lab  results 
may  be  edited  through  re-entry  of  the  code  and  the  result  while  in  the  Medical 
Edit  or  Lab  Results  options.  Previously  entered  lab  results  will  not  be  saved. 
An  entire  encounter  may  be  deleted  from  displays  of  the  patient's  data  by 
entering  "ERROR"  at  the  type  of  encounter  prompt  in  the  header  of  the  encounter. 
"E/"  error  entries  of  data  items  or  "ERROR"  entries  at  the  type  of  encounter 
prompt  do  not  actually  delete  a  data  item(s)  from  the  patient's  record  in  the 
database.  Instead,  the  encounter  and/or  codes  are  flagged  as  an  incorrect  entry 
and  are  bypassed  during  retrieval  functions.  Thus,  errored  entries  still 
require  disk  storage  space  and  can  be  accessed  in  the  system  files  for  audit 
purposes. 

Search-in-Context  Capability 

NOHIMS  has  an  extensive  search-in~context  capability  in  that  it  can  search 
for  the  co-occurence  of  data  items  in  a  worker/patient  record.  The  NOHIMS  file 
structure  in  both  components  provides  pointers  from  one  type  of  data  element  to 
another  within  the  component.  Both  components  use  the  patient/worker's  social 
security  number  to  uniquely  identify  the  patient  in  the  system,  so  it  is 
possible  to  track  workers  by  social  security  number  through  their  entire  work 
history  and  medical  encounters,  or  to  retrieve  co-occuring  data  items.  For 
example,  given  any  organizational  unit  of  the  agency,  both  the  personnel  in  that 
unit  and  the  work  environments  used  by  the  unit  are  known,  or  all  patients  who 
had  all  of  three  laboratory  tests  performed  can  be  retrieved  within  a  component. 

NOHIMS  will  also  search  in  context  on  a  patient/worker  name.  Liven  at 
least  two  letters  of  the  patient/worker's  last  name,  NOHIMS  will  display  all 
patient/workers  who  match  the  search  criteria.  Partial  response  input  may  also 
be  used  at  all  system  prompts  to  identify  uniquely  the  option  desired.  Partial 
response  input  of  directory  code  names  will  produce  an  alphabetic  list  of  code 
names  that  contain  the  partial  response  as  a  subset  of  the  directory  name. 

If  further  search-in-context  capabilities  are  desired  for  NOHIMS,  the 
system  can  be  linked  with  the  Medical  Query  Language  (MQL),  a  proprietary 
enhancement  for  COSTAR  developed  by  the  Laboratory  of  Computer  Science, 
Massachusetts  General  Hospital,  Boston,  Massachusetts.  MQL  is  a  high-level 
procedural  language  that  allows  nonprogramming  COSTAR  users  to  search  their 
database.  MQL  provides  powerful  and  flexible  retrieval  and  output  capabilities 
as  well  as  the  ability  to  select  subsets  of  the  database  for  further  analysis. 

The  Naval  Health  Research  Center,  San  Diego  has  acquired  a  3-year  license  for 
MQL  to  evaluate  its  potential  as  an  enhancement  for  NOHIMS. 
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In  the  industrial  component,  NOHIMS  uses  a  prompt  to  ask  the  user  if  the 
a  ta  that  have  been  entered  should  be  recorded  in  the  database.  This  prompt 
•  aally  asks  if  the  user  wishes  to  file,  edit,  or  ignore  the  data  entered.  The 
E"  for  Edit  response  allows  the  user  to  edit  the  data  that  have  just  been 
entered  by  returning  to  the  beginning  of  the  data  prompt  sequence.  The 
previously  entered  data  are  displayed  as  the  default  value  for  each  data  item. 
The  user  may  null  through  the  items  accepting  the  default  values,  or  enter  a  new 
value.  This  process  is  done  until  the  file,  edit,  or  ignore  prompt  is  reached 
again.  The  "I"  for  Ignore  response  nullifies  all  new  data  that  have  been 
entered  and  then  returns  the  user  to  the  previous  option  selection  level.  If 
"F"  for  File  is  entered,  NOHIMS  files  the  data  in  the  database  in  a  foreground 

process.  The  user  is  informed  of  filing  actions  with  a  "Filing  [ . ]" 

message.  When  filing  is  completed,  the  user  can  proceed  with  NOHIMS  operation. 


In  the  medical  component,  the  user  choses  to  file,  edit,  or  ignore  in  a 
fashion  similar  to  the  industrial  component.  The  filing  process  will  occur  in 
one  of  two  ways.  In  some  instances,  such  as  the  registration  and  system 
maintenance  filing  procedures,  NOHIMS  does  foreground  processing  and  indicates 
that  it  is  filing  with  a  "Please  wait  while  filing..."  or  "..."  message.  In 
other  cases,  such  as  encounter,  medical  edit,  or  lab  results  entry,  NOHIMS  files 
the  transactions  in  a  log  to  be  a_cessed  by  a  background  caretaker  job  called 
Monitor.  Monitor  then  files  the  data  into  the  patient  record  in  a  background 
process.  Monitor  protects  the  system  against  data  loss  by  filing  one  patient's 
data  at  a  time  and  speeds  up  data  entry  by  eliminating  waiting  time  while 
filing. 


Downloading  to  Magnetic  Tape 


All  of  the  data  and  routines  of  NOHIMS  can  be  downloaded  to  magnetic  tape 
using  operating  system  utilities.  Specific  routines  and/or  specific  globals 
(containing  patient  records  or  system  parameters)  may  be  selected  for  down¬ 
loading.  Within  NOHIMS,  the  only  feature  that  facilitates  downloading  of  data 
is  the  Archive  Patient  Records  suboption  in  the  medical  component  of  NOHIMS. 

This  function  was  designed  to  offload  inactive  patient  records  to  tape  or  to 
recall  patient  records  from  tape.  The  user  may  select  individual  records  or  a 
certain  group  of  records  to  be  archived  or  recalled.  Some  problems  were 
reported  to  the  COSTAR  Users'  Group  when  other  COSTAR  sites  attempted  to  execute 
the  Archive  Patient  Records  suboption  in  version  V.7.  Therefore,  the  Archive 
Patient  Records  function  in  NOHIMS  (based  on  COSTAR  version  V.7)  should  be 
tested  thoroughly  before  it  is  relied  upon  for  system  maintenance.  The 
documentation  that  was  generated  for  the  COSTAR  version  V.8  release,  however, 
stated  that  the  archiving,  de-archiving,  and  selective  recall  functions  in 
version  V.8  have  been  tested  and  are  now  functioning  properly.  Another  way  to 
be  sure  that  the  archiving  function  in  NOHIMS  is  working  properly  would  be  to 
selectively  move  the  version  V.8  Archive  Patient  Records  routines  into  NOHIMS  in 
place  of  the  V.7  routines. 
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The  data  entry  clerk  for  the  medical  component  of  NOHIMS  at  the 
Occupational  Health  Unit,  North  Island,  San  Diego,  California  estimated  that  he 
can  enter  between  30  and  40  complete  medical  encounters  per  day  of  data  entry 
(12-16  minutes  per  encounter).  The  time  required  to  enter  an  encounter  depends 
on  the  number  of  data  items  that  must  be  entered.  The  estimate  for  the  amount 
of  time  required  to  enter  data  from  an  industrial  survey  depends  greatly  on  the 
number  of  Occupational  Hazard  Data  Sheets  that  must  be  entered  as  part  of  the 
survey.  The  estimates  for  the  average  number  of  surveys  that  could  be  entered 
in  a  day  ranged  from  a  low  of  16  to  a  high  of  80. 

Both  the  industrial  and  medical  components  of  NOHIMS  have  extensive  edit 
capabilities  to  add,  change,  or  delete  data  from  the  database.  An  edit  function 
in  the  five  data  modules  of  the  industrial  component  is  used  to  edit  or  change 
information  that  has  already  been  entered  into  the  system.  Whether  or  not 
edited  values  are  retained  in  the  system  depends  on  the  function  used  to  perform 
the  edit  and  the  data  item  that  is  edited.  In  the  medical  component,  additions, 
deletions,  and  edits  to  the  patient  database  may  be  made  through  the  Patient 
Registration/Edit  option  of  the  Registration  module  and  the  Encounter  Entry, 
Medical  Edit,  and  Lab  Results  options  of  the  Enter  Medical  Data  module.  None  of 
the  edited  values  for  the  registration  items  is  stored  historically  in  the 
system.  Edits  to  the  encounter  record  are  retained  in  the  patient  files,  but 
are  bypassed  by  data  retrieval  functions. 

NOHIMS  can  search  for  the  co-occurence  of  data  items  in  a  worker/patient 
record.  Both  components  use  the  patient/worker’s  social  security  number  to 
uniquely  identify  the  patient  in  the  system,  so  it  is  possible  to  track  workers 
by  social  security  number  through  their  entire  work  history  and  medical 
encounters,  or  to  retrieve  co-occuring  data  items  within  a  component.  NOHIMS 
will  search-in-context  on  a  patient/worker  name.  If  further  search-in-context 
capabilities  are  desired  for  NOHIMS,  the  system  can  be  linked  with  the  Medical 
Query  Language  (MQL).  The  Naval  Health  Research  Center,  San  Diego  has  acquired 
a  3-year  license  for  MQL  to  evaluate  its  potential  as  an  enhancement  for  NOHIMS. 

Both  the  components  of  NOHIMS  use  a  prompt  to  ask  the  user  if  the  data  that 
have  been  entered  should  be  recorded  in  the  database.  In  the  industrial 
component,  filing  is  performed  as  a  foreground  process.  The  medical  component 
uses  a  background  caretaker  job  called  "Monitor"  to  perform  almost  all  of  the 
filing  tasks. 

All  of  the  data  and  routines  of  NOHIMS  can  be  downloaded  to  magnetic  tape 
using  operating  system  utilities.  The  medical  component  of  NOHIMS  has  an 
Archive  Patient  Records  suboption  that  was  designed  to  offload  inactive  patient 
records  to  tape  or  to  recall  patient  records  from  tape.  Other  COSTAR  users  have 
found  problems  when  using  this  option,  however.  This  option  is  reported  to  be 
fixed  in  00STAR  Version  V.8. 


Description  of  Information  Retrieval  Capabilities 

The  following  describes  the  system  modules  that  are  involved  with 
information  retrieval  for  each  component  of  NOHIMS,  and  the  main  functions  and 
features  of  each  module  involved  with  information  retrieval. 


Industrial  Component  Information  Retrieval  Capabilities 


There  are  eight  functions  in  the  industrial  component  of  NOHIMS  that  will 
retrieve  data  from  the  industrial  database.  These  are  the  display  functions  of 
the  five  data  modules — (1)  Display  Organization ,  (2)  Display  Personnel  Data, 

(3)  Display  Environment  Users,  (4)  Review  Environment  Information,  (5)  Display 
Survey  Data,  and  (6)  Display  Hazard  Data;  the  Hazard  Exposure/Examination  Report 
option  in  the  Personnel  Data  module;  and  the  Query/Report  module.  The  following 
paragraphs  describe  the  main  features  of  each  of  these  retrieval  functions. 

Agency  Data:  Display  Organization.  Using  this  option,  the  user  may 
display  all  or  any  portion  of  the  agency  organization.  The  display  is  organized 
so  that  the  hierarchical  configuration  of  the  unit  is  portrayed.  The  normal 
display  for  each  agency  unit  includes  the  unit's  name,  code,  site  location,  and 
the  number  of  environments  attached  to  it.  Also,  additional  information  such  as 
personnel  and  workplace  environments  applicable  to  each  agency  unit  may  be 
included  in  the  display  output.  If  this  latter  option  is  selected,  a  complete 
description  of  each  environment  is  displayed,  along  with  the  names,  employee 
identification  numbers,  and  the  date  that  the  persons  were  assigned  to  the 
particular  agency  unit. 


Personnel  Data:  Display  Personnel  Data.  This  function  allows  a  user  to 
display  the  personnel  data  for  a  selected  worker  or  all  workers  for  a  selected 
agency  unit.  The  display  that  is  produced  includes  personnel  demographic  data, 
the  current  agency  unit  to  which  the  worker  is  assigned,  the  date  the  worker  was 
assigned  to  that  unit,  and  information  for  the  worker's  currently  assigned  work 
environment.  The  user  may  also  opt  to  include  the  medical  examination 
information  in  the  display.  The  medical  examination  information  includes 
current  medical  examination  recommendations,  examination  status,  and  hazardous 
agent  exposure  information. 


Environment  Data;  Display  Environment  Users,  Review  Environment 
Information .  The  Display  Environment  Users  option  is  used  to  quickly  retrieve 
and  list  environment  descriptions  and  the  associated  agency  units.  No  other 
information  is  provided  in  the  display.  The  user  may  select  any  agency  unit 
environment(s)  for  display.  The  environment (s)  for  display  may  be  selected  by 
their  association  with  agency  units  or  by  keyword  content  of  their  description 
(such  as  "spill").  The  Re  view  Environment  Informal ion  option  will  retrieve 
environments  in  the  same  manner  as  the  Display  En”ironment  Users.  However,  the 
user  may  also  display  any  one  or  combination  of  the  following:  environment 


description,  organizational  users,  personnel  assigned  to  the  environment, 
mandatory  medical  requirements,  survey  references,  or  material  inventory. 


Survey  Data:  Display  Survey  Data.  The  Display  Survey  Data  option  will 
display  a  selected  survey,  or  any  or  all  surveys  associated  with  the  agency 
unit(s)  or  environment(s)  selected  for  display.  The  environrnent(s)  mc>'  be 
selected  by  their  association  with  agency  units  or  by  keyword  content  of  their 
description.  The  user  may  select  to  include  data  from  any  or  all  of  the  survey 
data  forms.  The  Industrial  Hygienist  Survey  form  display  retrieves  general 
workplace  facts  and  conditions;  the  Occupational  Hazard  Data  Sheet  display 
contains  material  sampling  and  exposure  data;  and  the  Material  Inventory  is  a 
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list  of  the  agents,  materials,  or  products  found  in  the  environments  associated 
with  the  survey. 

Hazard  Data:  Display  Hazard  Data.  All  current  information  contained  in 
the  Hazard  Table  for  a  selected  agent(s)  may  be  displayed  via  this  option.  The 
display  includes  the  agent  names,  code  numbers,  medical  monitoring  status, 
classification  category,  analytical  method  number,  sampling  and  analytical 
error,  exposure  limits,  scale,  authority,  action  level,  time-weighted  average 
limit,  short-term  exposure  limit,  ceiling  limit,  body  parts  or  organ  systems 
affected  by  the  agent,  and  medical  surveillance  protocol  for  the  agent.  The 
user  may  also  select  to  include  in  the  display  those  environments  that  contain 
the  selected  agent. 

Personnel  Data:  Hazard  Exposure/Examination  Report.  The  Hazard 
Exposure/Examination  Report  produces  the  hazard  exposure  summary  and  medical 
examination  requirement  reports  (Individual  Exposure  Examination  Reports)  for 
the  workers  that  are  selected.  In  addition,  the  Occupational  Health  Roster  (a 
roster  listing  employees  who  require  medical  examinations  within  each  applicable 
agency  unit)  and  a  Physical  Exam  Notification  Report  (a  medical  examination 
notice)  for  each  employee  in  the  Occupational  Health  Roster  may  also  be 
produced. 

There  are  a  variety  of  ways  to  select  individuals  for  generating  reports. 
Usually  the  Periodic  Exam  Preparation  suboption  is  used  to  select  all  personnel 
within  the  agency  who  were  born  in  a  specified  month  and  need  an  annual  physical 
examination.  NOHIMS  will  select  a  worker  for  a  physical  examination  only  if  the 
environments  associated  with  the  worker  contain  an  agent  with  mandatory  medical 
requirements  or  if  a  measured  hazardous  agent  concentration  value  of  an  agent  in 
the  worker's  environment(s)  has  exceeded  the  applicable  medical  action  level 
limits.  The  reports  can  be  produced  using  criteria  for  pre-placement 
examinations,  termination  examinations,  or  normal  periodic  examinations.  The 
user  may  also  select  specific  individuals  or  all  of  the  employees  of  a  specific 
agency  unit  by  using  the  Special  Examination  Preparation  suboption.  This 
suboption  also  produces  a  general  exposure  and  examination  report  for 
environments  rather  than  personnel.  All  reports  will  list  all  pertinent 
hazardous  agents,  concentration  sample  values,  and  associated  medical 
requirements. 

Once  a  particular  report  has  been  generated,  multiple  copies  of  the  report 
may  be  printed.  The  printing  of  a  report  may  also  be  restarted  at  a  failure 
point  or  at  the  beginning  of  the  report.  The  Occupational  Health  Roster  and 
Physical  Examination  Reports  can  also  be  printed  any  number  of  times.  The 
Delete  Old  Reports  suboption  is  used  to  erase  sets  of  report  specifications 
stored  in  the  system. 

Query/Report .  The  Query/Report  module  provides  an  ad  hoc  information 
re*"r-*-eval  ar,d  display  capability  that  extends  to  almost  every  data  item  in  the 
industrial  component.  To  generate  a  query,  the  user  first  defines  a  "command 
set.  The  command  set  contains  the  user's  selections  from  a  menu  progression. 

The  presentation  of  the  data  selection  menus  follows  a  logical  progression 
through  the  various  industrial  component  data  groups.  The  menu  at  any  point  in 
the  selection  process  allows  selection  of  only  those  data  groups  that  are 
possible  given  the  previous  data  group  selections  and  the  interrelationships  of 
those  data  groups  with  other  data  groups  in  the  component.  The  command  set 
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specifies  only  general  data  groups  and  data  items,  the  sequence  of  information 
retrieved,  and  the  user's  desire  to  specify  target  subjects  within  each  data 
group.  It  does  not  identify  individual  target  subjects.  The  selection  of 
individual  target  subjects  within  the  data  group  is  accomplished  interactively 
during  the  initial  portion  of  the  query  execution  process.  Therefore,  the  same 
command  set  may  be  used  to  retrieve  unlimited  combinations  of  specific  target 
data  accessible  by  the  sequence  of  the  general  query  command  set.  When  a  set  of 
individual  data  items  is  selected  for  the  query,  the  user  can  select  any  or  all 
of  the  data  items  in  the  group  for  retrieval.  Conditional  testing  of  a  data 
item  is  planned  as  a  future  enhancement.  Possible  testing  conditions  for  the 
industrial  component  will  include  comparison  to  a  given  numeric  value, 
comparison  to  a  given  numeric  interval,  testing  for  the  presence  or  absence  of  a 
data  item,  comparison  to  a  given  literal  value,  a  search  of  the  data  item 
content  for  a  given  single-  or  multi-word  literal,  and  comparison  to  an 
associated  table  of  values  if  applicable  to  the  data  item. 

A  command  set  is  stored  in  the  system  under  a  user  selected  name  until  the 
command  set  is  deleted  with  the  Erase  a  Query  File  option.  The  query  command 
sets  may  be  displayed  for  review  using  the  Display  a  Query  File  option.  There 
is  no  capability  to  edit  command  sets.  A  command  set  is  so  easily  built,  that 
it  is  simpler  to  create  a  new  command  set  than  to  modify  an  existing  one.  The 
output  display  format  of  the  retrieved  data  is  not  under  control  of  the  user. 

The  query  performs  a  simple  progressive  indentation  of  the  information  for  each 
unique  data  group,  much  like  an  outline.  The  absence  of  format  control  makes 
the  interactive  query  a  simple  and  quick  way  to  retrieve  data. 


Medical  Component  Information  Retrieval  Capabilities 


Four  modules  are  used  to  retrieve  data  in  the  medical  component  of  NOHIMS. 
These  are  the  Registration  module,  the  Display  Medical  Data  module,  the  Print 
Medical  Data  module,  and  the  COSTAR  Report  Generator.  The  Display  Registration 
option  in  the  Registration  module  and  the  Registration  Data  Check  option  in  the 
Display  Medical  Data  module  are  used  to  retrieve  registration  data.  The  COSTAR 
Report  Generator  module  option  menu  covers  three  different  functions.  These  are 
the  actual  COSTAR  Report  Generator,  the  Medical  Query  Language,  and  a  function 
that  retrieves  and  reformats  certain  data  for  research  purposes. 


Registration:  Display  Registration.  Display  Registration  allows  the  user 
to  view,  on  either  a  CRT  or  printer,  the  complete  set  of  registration  data  for  a 
patient.  The  registration  display  for  NOHIMS  contains  the  patient's  name,  sex, 
date  of  birth,  person  to  notify  in  emergency,  phone  number  in  emergency,  date  of 
registration,  social  security  number,  duty  station  or  activity,  and  primary 
clinic.  It  was  also  intended  that  the  patient  registration  would  include  the 
ethnic  background  of  the  patiert.  This  variable  has  not  yet  been  implemented  in 
NOHIMS. 


The  patient  to  be  displayed  can  be  identified  by  name  or  by  social  security 
number.  The  social  security  number  is  the  unit  number  that  uniquely  identifies 
the  patient  in  the  system.  The  patient  to  be  displayed  can  be  identified  with 
an  ambiguous  entry  of  the  name.  The  minimum  number  of  letters  of  the  patient's 
name  that  must  be  entered  at  the  Identify  Patient  prompt  is  two  letters  of  the 
last  name.  NOHIMS  will  then  list  all  patient  registered  in  the  medical 
component  that  meet  the  criteria  entered.  NOHIMS  does  not  search  for  patient 
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names  by  phonetics.  This  option  only  displays  registration  data.  No  changes 
can  be  made  to  the  registration  record  while  in  this  option.  If  the  user 
desires  to  edit  the  registration  record,  the  Patient  Registration/Edit  option 
must  be  used  to  display  and  then  edit  the  registration  record. 

The  registration  display  format  may  be  formatted  as  a  consensus  of  the 
users  desire.  The  specifications  for  the  registration  display  are  set  up  and 
altered  via  the  Registration  Functions  option  of  the  System  Maintenance  module. 
Only  one  registration  display  format  is  allowed  at  one  time.  However,  two 
registration  display  formats  may  be  saved  in  the  system. 

Display  Medical  Data.  The  Display  Medical  Data  module  allows  data  in  the 
medical  record  file  to  be  displayed  or  printed  in  a  variety  of  formats  and 
sequences.  The  reports  produced  by  the  Display  Medical  Data  module  include  List 
Encounters,  Encounter  Report,  Most  Recent  Encounter,  Flowchart,  Interactive 
Flowchart,  Index  Patient,  Status  Report,  Patient  Summary,  and  Registration  Data 
Check  (exactly  the  same  as  the  Patient  Display  in  the  Display  Registration 
option).  Like  the  Display  Registration  option,  patients  for  whom  data  are  to  be 
displayed  can  be  identified  by  either  the  patient's  name  or  social  security 
number.  Ambiguous  entries  of  the  patient's  name  are  allowed.  In  the  Display 
Medical  Data  module,  the  patient  is  identified  prior  to  selecting  the  report 
that  is  desired.  Thus,  a  variety  of  reports  may  be  displayed  or  printed  for  a 
patient  without  having  to  identify  the  patient  each  time. 

List  Encounters.  This  option  produces  a  list  of  all  past 
encounters  for  the  specific  patient.  The  list  includes  the  date 
of  the  encounter,  the  site  and  type  of  the  encounter,  and  the 
provider(s),  thus  providing  the  user  with  enough  information  to 
determine  which  encounter  or  encounters  should  be  viewed  in  more 
detail. 

Encounter  Report.  The  Encounter  Report  is  a  display  of  a  single 
visit  to  the  Occupational  Health  Unit.  There  are  two  main 
encounter  types  in  NOHIMS.  The  most  common  encounter  is  entered 
from  the  Physical  Exam  Data  Sheet  (PEDS)  and  the  Physical 
Examination  Findings  (PEX)  form.  If  a  patient  was  examined  as 
part  of  the  Asbestos  Medical  Surveillance  Program,  he/she  will 
have  an  additional  encounter  for  the  data  required  by  that 
program.  When  the  occupational  and  medical  history  data 
collection  forms  are  implemented,  the  data  will  be  entered  into 
encounters  separate  from  the  basic  PEDS  and  PEX  encounter. 

The  Encounter  Report  retrieves  all  data  items  entered  for  the 
encounter .  The  format  for  the  data  in  the  Encounter  Report 
cannot  be  changed  without  programming  intervention.  The 
Encounter  Report  displays  a  header  with  the  patient's  name,  sex, 
date  of  birth,  current  age,  unit  number  (SSN),  site  of  the  visit, 
type  of  visit,  visit  classification,  and  medical  care  providers. 

The  remaining  data  are  organized  by  divisions  of  the  medical 
record  (Administrative,  Diagnosis,  Physical  Findings,  Laboratory, 
and  Disposition).  For  each  coded  item,  NOHIMS  displays  the 
internal  code  and  the  long  name  of  the  code.  Modifier  names, 
statuses,  textual  comments,  and  laboratory  results  are  also 
displayed,  if  any. 
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The  user  selects  the  encounte1  to  be  displayed  by  date  of  the 
encounter.  No  other  criteria  may  be  used  to  select  which 
encounters  are  to  be  displayed  with  this  option  except  otherwise 
noted  below  under  Most  Recent  Encounter. 

Most  Recent  Encounter.  Most  Recent  Encounter  allows  the  user  to 
display  or  print  an  encounter  report  for  the  most  recent 
encounter  in  a  patient's  medical  record  or  to  progressively  view 
several  encounters  in  reverse  chronological  order. 

The  following  Display  Medical  Data  options  summarize  data  across 
encounters. 

Flowchart.  Flowchart  allows  the  user  to  track  prespecified  data 
items  across  encounters.  The  flowcharts  present  medical 
information  across  the  horizontal  axis  of  a  display  with 
corresponding  dates  of  entry  into  the  medical  record  displayed  on 
the  vertical  axis.  Modifiers,  statuses,  textual  comments,  and 
results  are  included  in  the  flowchart,  if  applicable.  Seven 
standard  flowchart  specifications  have  been  stored  in  NOHIMS. 
These  are  called  Hypertension,  Diabetes,  Red  Blood  Cell  Count, 
Congestive  Heart  Failure,  Kidney  Failure,  Urinalysis,  and  Liver 
Function  Tests.  Additional  flowchart  formats  may  be  defined 
using  the  Flowchart  Template  Edit  suboption  in  the  Directory 
option  of  the  System  Maintenance  module.  The  NOHIMS  system 
manager  may  specify  the  data  items  to  be  included  in  the 
flowchart  and  dictate  the  specific  format  of  the  flowchart  to  a 
limited  degree.  Which  encounters  are  to  be  summarized  by  the 
Flowchart  may  not  be  specified. 


Interactive  Flowchart.  This  option  permits  the  user  to  define  a 
flowchart  for  a  particular  patient.  The  specifications  for  the 
data  items  to  be  included  in  the  flowchart  are  not  stored  in  the 
system.  If  a  user  enters  the  same  specifications  frequently, 
they  can  be  stored  in  the  system  as  a  standard  flowchart  using 
the  Flowchart  Template  Edit  suboption.  The  interactive  flowchart 
is  the  quickest  way  to  track  a  single  data  item  through  the 
patient's  medical  record.  Interactive  Flowchart  has  the  same 
limitations  and  general  format  as  the  Flowchart  option  does. 


Index  Patient.  The  Index  Patient  option  displays  an  index  to 
all  of  the  sections  of  a  patient's  medical  record,  providing  a 
quick  review  of  the  main  features  of  the  record.  After  viewing 
the  index  list,  the  user  may  request  a  detailed  listing  of  any  or 
all  sections,  or  an  interactive  flowchart  based  on  the 
information  displayed  in  the  index.  The  format  for  this  report 
is  fixed.  If  a  data  item  has  a  short  name,  the  Index  Patient 
option  will  display  the  short  name.  Since  most  of  the  codes  in 
NOHIMS  have  short  names  that  are  used  in  data  entry,  this  report 
will  not  be  useful  unless  the  user  is  very  familiar  with  all  of 
the  data  entry  codes. 
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Status  Report.  The  Status  Report  summarizes  the  medical  record 
for  a  patient  in  a  predefined  format  that  cannot  be  changed 
without  programming  intervention.  It  is  a  summary  of  and  index 
to  all  divisions  of  the  patient's  medical  record.  The  report  may 
be  produced  in  its  entirety  or  by  selected  divisions.  For  each 
data  item,  the  Status  Report  displays  the  internal  code,  the  long 
name,  and  the  provider  who  most  recently  entered  the  data  item 
into  the  patient's  medical  record.  Most  recent  textual  comments 
and  laboratory  results  are  also  displayed. 

Patient  Summary.  This  option  summarizes  the  medical  record  for  a 
patient  in  a  user-defined  format.  Using  the  Patient  Summary 
Functions  suboption  of  the  System  Maintenance  module,  the  system 
manager  specifies  for  each  division  the  types  of  data  to  be 
included  in  the  display  (date,  abnormal  flag,  name  of  the  code, 
results,  text,  and  provider),  the  format  of  the  date  and  provider 
name,  and  the  location  of  each  data  item  on  the  page.  For 
certain  divisions,  the  system  manager  can  also  specify  that  only 
data  from  the  previous  N  encounters  and/or  the  previous  N  months 
will  be  included  in  the  report.  In  addition,  the  system  manager 
may  specify  data  items  to  be  included  in  an  optional  Data  Matrix. 

The  Data  Matrix  summarizes  selected  data  items  for  the  four  most 
recent  encounters.  Different  Data  Matrix  criteria  may  be 
specified  for  age  and  sex  groups. 

Registration  Data  Check.  The  Registration  Data  Check  option 
allows  the  user  to  display  or  print  the  registration  data  for  the 
selected  patient  without  leaving  the  Display  Medical  Data  Module. 

The  content  and  format  of  the  data  are  controlled  by  the 
Registration  Functions  described  in  the  Display  Registration 
section  above. 

All  of  the  previously  described  options  are  merely  display  options;  data 
may  not  be  edited  while  in  the  Display  Medical  Data  module.  Each  of  the  options 
contains  help  text  at  the  various  system  prompts  to  help  a  user  select  and 
display  the  report  that  is  desired.  Softcopies  of  the  reports  are  obtained  by 
selecting  the  report  option  while  logged  onto  a  CRT.  If  the  user  logs  onto  a 
hardcopy  device,  hardcopies  of  the  reports  may  be  obtained.  Hardcopies  of  the 
reports  may  also  be  obtained  via  the  Print  Medical  Data  module  described  next. 
The  ability  to  display  reports  can  be  restricted  to  certain  classes  of  users  and 
to  certain  devices  to  maintain  confidentiality  of  the  medical  data. 

Print  Medical  Data.  The  Print  Medical  Data  module  is  used  to  produce  all 
routine  hardcopy  medical  data  printouts.  This  module  contains  three  usable 
options:  Daily  Encounter  Reports,  Halt  Daily  Encounter  Report  on  Printer,  and 
Special  Print.  A  fourth  option,  Scheduled  Visit  Print  that  produces  Patient 
Summaries  for  patients  scheduled  for  an  appointment  for  a  given  date  and 
provider,  is  not  usable  in  NOHIMS  because  the  Scheduling  module  of  COSTAR  was 
not  implemented.  The  Scheduling  module  currently  available  in  COSTAR  is  usually 
considered  too  cumbersome  and  too  slow.  A  fifth  option,  Laboratory  Result 
Reporting,  was  not  implemented  in  NOHIMS.  The  main  features  of  each  of  the 
Print  Medical  Data  options  are  described  below. 


Daily  Encounter  Reports.  This  option  allows  the  user  to  print 
reports  for  patients  who  had  an  encounter  entered  on  that  day  or 
the  five  days  previous  to  that  day.  The  user  may  select  to  print 
an  encounter  report,  a  status  report,  all  previous  encounters,  or 
combinations  thereof.  The  order  of  the  printed  reports  usually 
is  determined  by  the  system  manager.  The  order  may  be  (1)  by 
patient's  last  name  alphabetically,  (2)  by  order  of  input,  (3)  by 
unit  number,  or  (4)  by  order  of  the  last  two  digits  of  the  social 
security  number  (the  last  order  would  not  be  useful  for  the 
NOHIMS  application).  The  user  may  specify  the  device  that  is  to 
print  the  reports. 

Halt  Daily  Encounter  Report  on  Printer.  The  Halt  Daily  Encounter 
Report  on  Printer  option  permits  the  device  printing  daily 
encounter  reports  to  be  halted  from  another  device. 

Special  Print.  Special  Print  allows  the  user  to  specify  a  group 
of  patients  for  whom  medical  reports  are  to  be  produced.  The 
reports  can  be  produced  according  to  a  list  of  names  that  is 
input,  alphabetically  by  patient's  last  name,  in  unit  number 
order,  or  by  the  last  digit  of  the  unit  number  (the  last  order 
would  not  be  useful  for  the  NOHIMS  application).  The  reports  to 
be  printed  (i.e.,  the  Status  Report,  Most  Recent  Encounter,  all 
Encounters,  Registration  Data  Check,  Flowcharts,  or  any 
combinations  thereof)  may  be  specified  for  each  patient 
individually  or  for  the  group  of  patients  as  a  whole.  Once  the 
list  of  names  is  created,  it  is  stored  in  the  database  associated 
with  the  device  used  to  create  the  list  for  future  use.  Special 
print  files  may  be  edited,  restarted,  and  deleted  from  the 
system. 

Each  of  the  Print  Medical  Data  options  contains  help  text  at  the  various 
system  prompts  to  help  a  user  select  and  print  the  reports  that  are  desired. 

The  ability  to  print  reports  can  be  restricted  to  certain  classes  of  users  and 
to  certain  devices  to  maintain  confidentiality  of  the  medical  data. 

COSTAR  Report  Generator.  The  COSTAR  Report  Generator  (CRG)  has  the 
capability  of  providing  listings  and  cross  tabulations  of  any  variables 
contained  in  the  NOHIMS  database.  Additionally,  percentages,  totals,  and 
subtotals  may  be  computed  for  any  specifed  distribution.  This  option  serves  to 
satisfy  data  retrieval  needs  not  met  by  the  standardized  reports  described 
above. 

The  listings  produced  by  the  CRG  may  include  divisions,  actual  data  items, 
or  data  associated  with  a  data  item  (results,  statuses,  modifiers,  and  text). 

The  user  may  also  modify  data  items  with  selection  criteria  such  as  last,  most 
recent,  number  of,  etc.  The  format  for  the  listings  is  defined  by  the  user 
within  certain  parameters.  Data  items  are  listed  across  the  horizontal  axis,  so 
the  user  is  limited  to  80  columns  of  data  on  a  CRT  or  132  columns  of  data  on  a 
hardcopy  device.  The  system  sets  default  values  for  all  data  items,  such  as 
field  title,  field  width,  and  data  format.  These  default  values  may  be 
overridden  by  the  user.  Listings  may  be  produced  in  one  of  three  ways:  (1) 
order  of  encounter  input,  (2)  alphabetic  order  by  the  patient  s  name,  or  (3) 
encounter  date  order. 


The  cross  tabulations  provided  by  the  CRG  may  be  on  divisions,  actual  data 
items,  or  data  associated  with  a  data  item  (results,  statuses,  modifiers,  and 
text).  The  user  may  also  modify  data  items  with  selection  criteria  such  as 
last,  most  recent,  number  of,  etc.  The  user  may  define  one  set  of  up  to  3-way 
tables  and  may  specify  the  down,  across,  and  by  variables  within  certain  limits. 
Variables  that  require  a  new  category  for  each  unique  value  may  not  be  used  in 
the  across  position.  The  user  can  define  groupings  by  either  discrete 
categories  (e.g.,  male  and  female)  or  continuous  categories  (e.g.,  10-19  years 
of  age).  The  user  may  select  to  generate  another  set  of  tables  that  contains 
percentages  and  may  specify  the  denominator  of  the  percentages  (row,  column,  or 
table  total,  or  combinations  thereof).  NOHIMS  does  not  compute  means, 
deviations  from  a  mean,  or  other  statistics.  The  CRG  does  not  produce  graphic 
representations  of  data. 

The  user  may  specify  up  to  approximately  22  selection  criteria  for  defining 
subsets  of  patients  to  be  listed  or  tabulated.  Selections  may  be  made  on  the 
basis  of  the  presence  or  absence  of  a  data  item,  the  value  of  a  data  item,  or 
the  presence  or  absence  of  data  in  a  particular  division,  or  combinations 
thereof.  The  user  may  specify  alternate,  necessary,  nested  alternate,  or  nested 
necessary  conditions,  or  a  combination  thereof.  At  the  time  of  running  the 
report,  the  user  may  specify  a  range  of  encounter  dates  to  be  included  in  the 
tally.  If  a  range  of  encounter  dates  is  specified,  the  CRG  will  only  search 
encounters  for  those  dates  for  valid  data.  Otherwise,  the  CRG  will  search  the 
entire  database  for  valid  encounters/patients. 

The  CRG  also  allows  the  user  to  specify  whether  data  will  be  listed  or 
tabulated  in  patient  mode  or  in  visit  mode.  If  «.  ie  patient  mode  is  selected, 
one  line  in  the  list  and  one  tally  in  a  tabulation  will  be  made  for  each  patient 
that  meets  the  given  selection  criteria.  If  the  visit  mode  is  chosen,  the 
system  will  utilize  one  line  in  the  listing  and  one  tally  in  the  tabulation  for 
each  encounter  entered  in  the  system  for  the  patient  that  meets  the  selection 
criteria. 

To  run  a  CRG  report,  the  user  first  defines  a  set  of  report  specifications. 
These  specifications  are  stored  in  the  system  under  a  user-selected  name  of  up 
to  20  characters.  The  report  specifications  may  be  altered  at  any  time,  run  as 
many  times  as  desired,  renamed,  and  deleted  when  no  longer  needed.  When  editing 
the  report  specifications,  NOHIMS  displays  each  specification.  The  user  may 
change  the  specification  or  null  through  the  prompt  to  retain  the  specification. 
The  edited  specifications  may  be  saved  to  the  same  report  name  or  to  a  new 
report  name.  NOHIMS  will  display  a  list  of  reports  stored  in  the  system  along 
with  the  last  time  the  specifications  were  edited. 

When  a  CRG  run  is  performed,  the  tabulations  produced  by  the  report  are 
stored  in  a  working  file  to  be  printed  at  a  later  date.  Listings,  on  the  other 
hand,  are  produced  as  the  CRG  proceeds  through  the  database  and  are  not  stored 
in  the  system.  Tabulations  that  are  no  longer  needed  may  be  deleted  from  the 
working  storage. 

The  user  may  job  queue  a  CRG  report.  The  user  may  specify  the  date  and 
time  the  job  is  to  be  run,  may  link  the  job  to  previous  jobs,  and  may  specify 
the  device  that  is  to  be  used  to  run  the  report.  Currently,  only  one  CRG  report 
may  be  run  at  a  time.  This  is  a  limitation  of  the  present  operating  system, 
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however.  The  device  that  is  being  used  to  run  the  report  will  be  tied  up  until 
the  report  is  completed.  Hardcopy  of  reports  may  be  obtained  by  running  the  CRG 
report  on  a  hardcopy  device  or  by  printing  the  working  storage  on  a  hardcopy 
device.  Softcopies  of  reports  may  be  obtained  by  running  the  report  on  a  CRT. 
These  reports  are  useful  for  quick  investigations  into  the  database  or  for 
testing  new  report  specifications.  Extensive  help  text  enables  the  user  to 
utilize  the  job  queue  and  all  other  CRG  functions. 

Query  Language.  The  Medical  Query  Language  provides  a  more  powerful  tool 
for  selecting  and  retrieving  data  than  the  CRG.  For  complicated  queries, 
however,  the  Medical  Query  Language  requires  more  effort  on  the  part  of  the  user 
to  understand  the  content  and  format  of  NOHIMS'  data  files  and  the  Medical  Query 
Language's  programming-like  conventions.  The  Medical  Query  Language  calculates 
sums,  means,  sum  of  squares,  and  standard  deviations.  It  also  has  the  ability 
to  graph  up  to  three  variables.  The  Naval  Health  Research  Center  has  a  3-year 
license  to  evaluate  the  potential  of  the  Medical  Query  Language  as  an 
enhancement  for  NOHIMS. 

Construct  SSN  Global,  Clear  SSN  Global,  Produce  Fixed  Length  Record, 
Transfer  Global  to  Tape,  Move  SSNs  from  Indus  UCI.  These  five  options  are  used 
to  retrieve  certain  data  and  reformat  it  into  a  fixed-length  record  that  can  be 
used  with  other  statistical  packages.  The  Construct  SSN  Global  option  uses 
normal  CRG  procedures  to  select  specified  patients  and  stores  the  patients' 
social  security  numbers  in  a  special  file.  The  Clear  SSN  Global  is  used  to 
delete  all  of  the  social  security  numbers  in  the  special  file.  The  Produce 
Fixed  Length  Record  option  extracts  certain  demographic  data  and  specified 
physical  examination  findings  and  laboratory  results  and  reorganizes  them  into  a 
fixed  format.  The  Transfer  Global  to  Tape  option  writes  the  fixed-format  data 
to  tape  for  transfer  to  other  systems.  The  Move  SSNs  from  Indus  UCI  option 
transfers  lists  of  social  security  numbers  produced  via  the  Query/Report  module 
of  the  industrial  component  into  the  medical  component.  The  lists  of  social 
security  numbers  may  be  combined  with  another  list  in  the  medical  component,  or 
a  new  list  may  be  created  in  the  medical  component . 


Summary 

There  are  eight  functions  in  the  industrial  component  of  NOHIMS  that  will 
retrieve  data  from  the  industrial  database.  These  are  the  display  functions  of 
the  five  data  modules — Display  Organization ,  Display  Personnel  Data,  Display 
Environment  Users,  Review  Environment  Information,  Display  Survey  Data,  and 
Display  Hazard  Data;  the  Hazard  Exposure/Examination  Report  option  in  the 
Personnel  Data  module;  and  the  Query/Report  module.  The  display  options  of  the 
five  data  modules  can  retrieve  and  display  information  both  specific  to  the  data 
module  (e.g.,  agent  names  and  exposure  limits)  and  from  relationships  between 
the  modules  (e.g.,  environments  that  contain  a  particular  agent).  The  Hazard 
Exposure/Examination  Report  option  produces  the  hazard  exposure  summary  and 
medical  examination  requirement  reports  for  selected  workers.  The  Query/Report 
module  provides  an  ad  hoc  information  retrieval  and  display  capability  that 
extends  to  almost  every  data  item  in  the  industrial  component. 

Four  modules  are  used  to  retrieve  data  in  the  medical  component  of  NOHIMS. 
These  are  the  Registration  module,  the  Display  Medical  Data  module,  the  Print 
Medical  Data  module,  and  the  COSTAR  Report  Generator.  The  Display  Registration 
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option  in  the  Registration  module  and  the  Registration  Data  Check  option  in  the 
Display  Medical  Data  module  are  used  to  retrieve  registration  data.  Three  of 
the  options  in  the  Display  Medical  Data  module  retrieve  information  about 
individual  encounters;  five  other  options  summarize  data  across  encounters.  The 
Print  Medical  Data  options  print  hardcopies  of  Encounter  Reports,  Patient 
Summaries,  Status  Reports,  and/or  Flowcharts  for  particular  groups  of 
individuals.  The  COSTAR  Report  Generator  options  cover  three  different 
functions.  These  are  the  actual  COSTAR  Report  Generator,  the  Medical  Query 
Language,  and  a  function  that  retrieves  and  reformats  certain  data  for  research 
purposes.  The  COSTAR  Report  Generator  produces  listings  and  cross  tabulations 
according  to  user-defined  criteria.  The  Medical  Query  Language  is  a  more 
powerful  data  retrieval  language  that  is  under  examination  as  a  future 
enhancement  for  NOHIMS.  Five  options  produce  a  fixed  length,  fixed  format 
record  from  COSTAR  data  for  use  in  research  functions. 


Evaluation  of  Information  Retrieval  Capabilities 

The  six  medical  care  providers,  five  industrial  hygienists,  and  two  system 
managers  were  asked  to  evaluate  NOHIMS'  information  retrieval  capabilities.  The 
questions  divided  the  capabilities  into  two  functions:  (1)  standard  reports 
produced  by  NOHIMS  and  (2)  user-defined  report  functions  such  as  the  COSTAR 
Report  Generator  in  the  medical  component  and  the  Query/Report  module  in  the 
industrial  component.  The  interviewees  were  asked  to  name  the  standard  reports 
that  they  use  or  receive  and  the  ways  in  which  they  use  them.  They  also 
assessed  the  adequacy  and  usefulness  of  both  the  standard  and  user-defined 
reports.  The  questions  we  used  to  evaluate  NOHIMS'  information  retrieval 
capabilities  may  be  found  in  Appendix  A,  Cohiponent  7. 

Table  16  shows  the  standard  reports  that  each  group  of  NOHIMS  users 
receives  or  uses.  All  of  the  medical  care  providers  use  the  Individual  Exposure 
Examination  Report;  half  or  less  of  the  medical  care  providers  use  the  other 
standard  reports.  Since  the  Physical  Exam  Notification  Report  and  the 
Occupational  Health  Roster  were  designed  for  use  by  the  occupational  health 
technicians  in  scheduling  physical  examinations,  it  is  not  surprising  that  few 
other  medical  care  providers  use  these.  The  Encounter  Report,  Patient  Data 
Sheet,  and  Flowcharts  display  medical  data,  yet  few  providers  utilize  these 
reports.  Only  one  person  has  used  the  Status  Report;  however,  this  is 
consistent  with  the  NOHIMS  developers  recommendation  that  this  report  not  be 
used  because  of  its  awkward  format. 

The  main  standard  report  that  the  industrial  hygienists  use  is  the 
Industrial  Hygiene  Survey.  All  of  the  industrial  hygienists  use  this  report. 
Three  of  the  five  hygienists  (60%)  also  use  or  receive  the  Individual  Exposure 
Examination  Report.  The  San  Diego  system  manager  receives  or  uses  all  of  the 
reports,  except  the  Status  Report,  Flowcharts,  and  the  Industrial  Hygiene 
Survey.  The  Rremerton  system  manager  uses  or  receives  only  the  Industrial 
Hygiene  Survey,  a  reflection  of  the  fact  that  the  medical  module  has  not  been 
implemented  at  Bremerton  yet  and  he  has  a  collateral  position  as  an  industrial 
hygienist  . 

Table  17  presents  the  ways  in  which  the  users  utilize  the  standard  NOIHMS 
reports.  The  interviewees  use  the  standard  reports  for  a  variety  of  purposes. 
The  use  that  was  mentioned  most  frequently  is  to  communicate  with  others  which 


TABLE  16 

Standard  NOHIMS  Reports  Used 

(Number  who  mentioned  report;  percentage  of  group  who  uses  report) 


Medical 

Care 

Providers 

% 

Industrial 

Hygiene  Survey 

N/A 

- 

Physical  Exam 
Notification 

Report 

1 

17 

Occupational 

Health 

Examination 

Roster 

2 

33 

Individual 

Exposure 

Examination 

Report 

6 

100 

Patient  Data 

Sheet  (Patient 
Summary ) 

3 

50 

Encounter  Report 

3 

50 

Status  Report 

1 

17 

Industrial 
Hygienists  % 

5  100 

0  0 

0  0 

3  60 

N/A 

N/A 

N/A 

N/A 


System 
Managers  % 

1  50 

1  50 

1  50 

1  50 

1  50 

1  50 

0  0 


Flowcharts 


2 


33 


0 


0 


TABLE  17 

Uses  for  Standard  NOHIMS  Reports 
(Number  who  mentioned  use;  multiple  answers  allowed) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

System 

Managers 

TOTAL 

%  of 
Total 

Interviewed 

Communicate 

with  others 

4 

4 

2 

10 

77 

Prepare  required 

reports 

1 

5 

1 

7 

54 

Plan  workloads 

1 

4 

1 

6 

46 

Provide  direct 

patient  care 

5 

0 

0 

5 

38 

Other: 

Replace 

lost 

charts/chits 

1 

0 

0 

1 

8 

TOTAL  INTERVIEWED 

6 

5 

2 

13 

100 

was  mentioned  by  77  percent  of  those  interviewed.  This  percentage  included 
people  who  provide  data  for  others,  such  as  the  San  Diego  system  manager.  The 
standard  reports  are  also  used  to  prepare  required  reports  by  54  percent  of 
those  interviewed.  Forty-six  percent  of  the  people  interviewed  said  they  use 
the  standard  reports  to  plan  workloads.  Almost  all  of  the  industrial  hygienists 
mentioned  specifically  that  they  use  the  Industrial  Hygiene  Survey  to  plan 
future  surveys.  Five  out  of  six  of  the  medical  care  providers  said  that  they 
used  the  standard  reports  in  direct  patient  care.  One  medical  care  provider 
mentioned  the  usefulness  of  having  a  NOHIMS  medical  record  when  paper  charts  or 
lab  chits  were  lost. 

Tables  18-19  contain  the  users'  ratings  of  the  adequacy  and  usefulness  of 
the  standard  NOHIMS  reports.  All  of  the  individuals  interviewed  thought  that 
the  NOHIMS  standard  reports  at  least  adequately  meet  their  needs,  and  two  of  the 
industrial  hygienists  (15%  of  the  total)  rated  the  standard  NOHIMS  reports 
as  more  than  adequately  meeting  their  needs  (see  Table  18).  Table  19  shows  that 
every  one  interviewed  thought  that  the  standard  NOHIMS  reports  were  very  useful. 

We  also  asked  the  medical  care  providers  to  evaluate  the  usefulness  of  the 
standard  medical  reports  in  the  day-to-day  provision  of  medical  care  and  to 
assess  the  effect  of  the  standard  reports  on  the  quality  of  medical  care 
provided  (see  Tables  20-21).  Eighty-three  percent  of  the  medical  care  providers 
thought  that  the  standard  medical  reports  were  very  useful  and  also  that  the 
reports  had  had  at  least  a  beneficial  effect  on  the  quality  of  medical  care. 

One  of  the  physicians  stated  that  "the  data  collected  now  are  better  than  the 
old  data  in  the  charts."  Another  physician  was  very  negative  about  the 
usefulness  of  the  standard  reports  and  the  effect  of  the  reports  on  the  quality 
of  medical  care  provided.  He  felt  that  the  reports  had  a  detrimental  effect 
because  the  Navy  administration  has  not  yet  accepted  NOHIMS  as  the  standard. 

The  medical  care  providers  are  required  to  duplicate  efforts  to  produce  the 
reports  taking  away  resources  from  direct  patient  care. 

We  then  asked  the  interviewees  to  comment  on  additional  standard 
information  or  reports  that  would  be  helpful  to  have.  Table  22  contains  the 
suggestions  that  were  made.  Each  of  these  items  was  mentioned  by  only  one  of 
the  interviewees.  Suggestions  included  reports  of  calibration  data,  equipment 
data,  lab  data  for  certain  industrial  hygiene  tests,  and  personnel  data;  auto 
triggering  of  monthly  reports;  ability  to  generate  a  list  of  workers  above  a 
certain  agent  measurement  level;  flagging  of  agent  measurements  over  50  percent 
of  the  Threshold  Limit  Value  and  of  extreme  abnormalities;  and  periodic  reports 
of  medical  process  data  by  provider.  One  occupational  health  technician  wanted 
to  access  the  industrial  component  to  obtain  exposure  and  normal  levels  for 
patients  who  come  to  the  clinic  on  their  own.  A  physician  wanted  to  see 
previous  exposure  and  work  history  data  for  patients.  One  industrial  hygienist 
requested  the  ability  to  generate  reports  that  contain  agent  measurement  values 
for  the  sampled  worker  for  inclusion  in  his  medical  record  and  in  the  medical 
records  of  other  workers  in  the  same  shop.  An  even  more  useful  capability  would 
be  a  mechanism  that  would  automatically  pass  the  agent  measurement  value(s)  to 
the  electronic  medical  record.  Reports  of  the  risk  assessment  code  for  hazards 
were  also  requested.  New  survey  data  forms  that  contain  data  on  the  risk 
assessment  code  were  put  into  use  at  Bremerton  in  April  1986.  It  should  now  be 
possible  to  produce  these  codes  in  some  form  of  a  report. 


TABLE  18 

Adequacy  of  Standard  NOHIMS  Reports 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

System 

Managers 

TOTAL 

More  than 
adequately 
meets  needs 

0 

2 

0 

2 

Adequately 

meets  needs 

6 

3 

2 

11 

Less  than 
adequately 
meets  needs 

0 

0 

0 

0 

Is  not 

relevant  0  0  00 


TABLE  19 

Usefulness  of  Standard  Reports 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

System 

Managers 

TOTAL 

%  of 
Total 

Interviewed 

Very  useful 

6 

5 

2 

13 

100 

Somewhat  useful 

0 

0 

0 

0 

0 

Not  useful 

0 

0 

0 

0 

0 

VC 
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TABLE  20 

Usefulness  of  Standard  Medical  Reports 
in  Day-to-Day  Provision  of  Medical  Care 
According  to  Medical  Care  Providers 
(Number  who  mentioned  rating) 


TOTAL 


%  of  Total 
Interviewed 


1 

Very  useful 

5 

83 

Somewhat  useful 

0 

0 

*■: 

t: 

Not  useful 

1 

17 

Not  used 

0 

0 

TABLE  21 

Effect  of  Standard  Medical  Reports  on  Quality  of  Medical  Care 
According  to  Medical  Care  Providers 
(Number  who  mentioned  rating) 


7o  of  Total 


TOTAL 

Interviewed 

Very  beneficial 

3 

50 

Beneficial* 

2 

33 

Somewhat  beneficial 

0 

0 

No  effect 

0 

0 

Somewhat  detrimental 

0 

0 

Very  detrimental 

1 

17 

TOTAL  INTERVIEWED  6  100 


*  Category  added  by  respondents 


TABLE  22 

Additional  Information/Reports  That  Would  Be  Helpful 
(All  mentioned  once) 


•  Calibration  data 

•  Equipment  data 

•  Lab  data  for  certain  IH  tests 

•  Personnel  data 

•  Risk  assessment  code  for  hazards  [New  survey  forms 
put  into  use  at  Bremerton  in  April  1986  contained 
this  information] 

•  Auto  triggering  of  monthly  reports 

•  Access  to  IH  data  to  obtain  exposure  and 
normal  levels 

•  Periodic  Medical  Director's  report  with 
basic  process  data  by  provider 

•  Previous  exposure  and  work  history  data 

•  Flagging  of  measurements  over  50%  of  TLV 

•  Flagging  of  extreme  abnormalities 

•  Generating  a  list  of  people  above  a 
certain  agent  measurement  level 

•  Reports  of  the  agent  measurement  value  for  the  person 
sampled  for  inclusion  in  his/her  medical  record  and 
the  medical  records  of  other  workers  in  the  shop 
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We  next  asked  the  users  to  evaluate  the  NOHIMS  user-defined  reporting 
capabilities,  including  the  Interactive  Flowchart  and  the  COSTAR  Report 
Generator  in  the  medical  component  and  the  on-line  look-up  and  the  Query/Report 
module  in  the  industrial  component.  Table  23  shows  that  none  of  the  medical 
care  providers  used  either  of  the  medical  component's  user-defined  reporting 
capabilities,  although  the  system  manager  at  San  Diego  has  used  both.  All  of 
the  industrial  hygienists  and  both  of  the  system  managers  had  used  both  the  on¬ 
line  look-up  and  the  Query/Report  module. 

Since  only  one  person  had  used  the  medical  component  user-defined  report 
capabilities,  we  are  unable  to  fully  evaluate  the  uses  and  usefulness  of  these 
capabilities  to  NOHIMS  users.  The  San  Diego  system  manager  who  had  used  the 
options,  however,  thought  that  they  were  very  useful.  He  used  them  to  provide 
information  for  other  users. 

Table  24  shows  that  the  main  information  retrieved  with  the  on-line  look-up 
and  the  Query/Report  module  in  the  industrial  component  are  survey-specific 
information  which  is  retrieved  by  100  percent  of  the  users,  and  shop-specific 
information  which  is  accessed  by  83  percent  of  the  users.  The  industrial 
hygienists  and  system  managers  also  retrieve  patient-specific  exposures  (33%  of 
users),  administrative  data  (33%),  survey  lab  results  (17%),  environment-related 
data  (17%),  and  hazard-related  data  (17%),  but  to  a  lesser  degree. 

The  main  use  for  the  data  retrieved  with  these  industrial  component  user- 
defined  report  functions  is  resource  management  (see  Table  25).  Again,  the 
industrial  hygienists  mentioned  using  the  data  to  plan  surveys  and  workloads. 
Other  less  frequent  responses  included  use  in  direct  patient  care,  assessment  of 
quality  of  care,  tracking  a  hazard,  and  responding  to  compensation  claims.  The 
direct  patient  care  and  quality  of  care  uses  were  mentioned  by  one  industrial 
hygienist  who  checks  to  see  if  and  how  often  workers  have  been  called  up  for 
examinations;  if  they  are  sick,  she  looks  up  their  exposures  in  NOHIMS.  One 
system  manager  retrieves  data  for  use  by  others.  Table  26  shows  that  100 
percent  of  the  industrial  hygienists  and  system  managers  rated  the  on-line  look¬ 
up  and/or  Query/Report  module  as  very  useful. 

Summary 

The  Individual  Exposure  Examination  Report  is  the  most  frequently  used 
standard  report;  nearly  everyone  uses  it.  The  standard  NOHIMS  reports  produced 
by  the  medical  component  are  used  by  half  or  less  of  the  medical  care  providers. 
The  main  uses  for  the  standard  reports  are  communicating  with  others  (77%  of 
users  mentioned  use),  preparing  required  reports  (54%),  planning  workloads 
(46%),  and  in  providing  direct  patient  care  (38%).  All  of  the  users  rated  the 
standard  NOHIMS  reports  as  at  least  adequate  for  meeting  needs  and  all  of  the 
users  thought  that  they  were  very  useful.  The  medical  care  providers  generally 
thought  that  the  standard  reports  were  very  useful  in  the  day-to-day  provision 
of  medical  care  and  that  the  standard  reports  have  had  a  beneficial  effect  on 
the  quality  of  medical  care.  The  medical  care  providers  are  not  using  the  user- 
defined  reporting  capabilities  in  the  medical  component  so  we  could  not  evaluate 
the  usefulness  of  these  functions.  All  of  the  industrial  hygienists  and  system 
managers  use  the  on-line  look-up  and  Query/Report  module  in  the  industrial 
component.  These  are  used  mostly  for  resource  management  (83%  mentioned  use) 
and  to  look  up  survey-specific  information  (100%  mentioned  this  information)  and 


TABLE  23 

User-Defined  Information  Retrieval  Capabilities  Used 
(Number  who  mentioned  capability;  multiple  answers  allowed) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

System 

Managers 

TOTAL 

%  of 
Total 

Interviewed 

Medical  component 

Interactive 

Flowchart 

0 

- 

1 

1 

14 

Report  Generator 
runs 

0 

- 

1 

1 

14 

None 

6 

- 

0 

6 

86 

NUMBER  INTERVIEWED 

6 

- 

1 

7 

Industrial  component 

On-line  look-up 

- 

5 

2 

7 

100 

Query/Report 

Module 

- 

5 

2 

7 

100 

NUMBER  INTERVIEWED 

— 

5 

2 

7 

TOTAL  INTERVIEWED 

6 

5 

2* 

13* 

*  Two  system  managers  were  interviewed.  The  one  from  San  Diego  has  access  to 
both  the  industrial  and  medical  components.  The  one  from  Bremerton  does 
not  have  access  to  the  medical  component  since  it  has  not  been  implemented 


TABLE  24 

Information  Retrieved  with  On-Line  Look-Up  and/or  the  Query/Report  Module 
(Number  who  mentioned  type  of  information;  multiple  answers  allowed) 


Industrial 

Hygienists 

System 

Managers 

TOTAL 

%  of 

Total  Who 
Answered 

Survey-specific 

information 

4 

2 

6 

100 

Shop-specific 

exposures 

3 

2 

5 

83 

Verify  or  look-up 
administrative  data 

1 

1 

2 

33 

Patient-specific 

exposures 

1 

1 

2 

33 

Environment- related 
data 

1 

0 

1 

17 

Hazard-related  data 

1 

0 

1 

17 

Survey  lab  results 


17 


5 


'  ^ 


TABLE  25 

Uses  for  On-Line  Look-Up  or  Query/Report  Module 
(Number  who  mentioned  use;  multiple  answers  allowed) 


Industrial 

Hygienists 


System 

Managers 


TOTAL 


%  of 

Total  Who 
Answered 


Resource  management 
Direct 

patient  care 

Assessment  of 
quality  of  care 

Other: 

Track  a 

particular 

hazard 

Respond  to 

compensation 

claims 

For  use  by 
others 


TOTAL  WHO  ANSWERED 


No  Comment 


TOTAL  INTERVIEWED 


w*  /  .*  . 
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TABLE  26 

Usefulness  of  On-Line  Look-Up  and/or  Query/Report  Module 
(Number  who  mentioned  rating) 


Industrial 

Hygienists 

System 

Managers 

TOTAL 

%  of 

Total  Who 
Answered 

Very  useful 

4 

2 

6 

100 

Somewhat  useful 

0 

0 

0 

0 

Not  useful 

0 

0 

0 

0 

TOTAL  WHO  ANSWERED  4 


2  6  100 


No  Comment 


1 


0 


1 


TOTAL  INTERVIEWED  5 


2 


7 


97 


shop-specific  exposures  (83%).  All  of  the  industrial  hygienists  and  system 
managers  rated  the  industrial  component  user-defined  information  retrieval 
capabilities  as  very  useful. 


ASSESSMENT  OF  SECURITY  FEATURES 

Since  NOHIMS  contains  confidential  medical  information,  it  is  very  critical 
that  NOHIMS  have  adequate  security  protection  to  ensure  the  privacy  of  the  data 
stored  in  the  database.  In  addition,  data  obtained  from  NOHIMS  are  used  for 
medical  monitoring  and  may  be  used  as  legal  evidence  in  various  Navy  legal 
proceedings;  therefore,  the  system  must  be  protected  from  both  internal  and 
external  corruption.  This  section  of  the  Evaluation  Report  documents  the 
efforts  we  made  to  determine  if  NOHIMS  adequately  meets  the  security  needs  of 
the  Navy.  The  first  section  contains  an  objective  verification  that  NOHIMS 
contains  the  logical  and  physical  security  controls  that  were  outlined  in  the 
NOHIMS  System  Decision  Paper  (SDP)  written  in  June  of  1984.  The  second  section 
is  a  subjective  evaluation  of  the  adequacy,  usage,  and  necessity  of  the  NOHIMS 
security  features  by  the  NOHIMS  developers  at  the  Naval  Health  Research  Center 
(NHRC),  higher  level  Navy  managers,  and  system  users  at  San  Diego  and  Bremerton. 


Description  of  NOHIMS  Security  Features 

The  SDP  clearly  spells  out  both  the  logical  and  physical  security  controls 
that  NOHIMS  should  have.  The  logical  controls  include:  (1)  passwords  to 
log-on,  (2)  limiting  access  to  certain  functions  by  password,  (3)  limiting 
access  to  files  by  device,  (4)  time-outs  if  a  terminal  is  not  used  for  a  period 
of  time,  (5)  scrambled  identification  codes,  (6)  separate  files  for  personnel 
information  and  for  medical  information,  and  (7)  masked  fields.  Physical 
security  controls  as  outlined  in  the  SDP  are  to  include:  (1)  use  of  cipher 
locks  on  the  computer  room  door,  (2)  log  book  entry  of  noncomputer  staff 
entering  the  main  computer  room,  and  (3)  a  record  of  batch  programs  that  the 
operator  initiates  on  the  system.  The  developers  of  the  SDP  felt  that  these 
physical  security  controls  should  prevent  unauthorized  access  to  the  system. 

The  following  sections  document  the  NOHIMS  logical  and  physical  security 
controls . 


NOHIMS  Logical  Security  Features 

The  following  are  descriptions  of  the  logical  security  features  of  NOHIMS. 

Sign-On/Off  Procedures.  Each  user  of  NOHIMS  is  assigned  an  identification 
code  of  from  three  to  five  characters.  This  code  is  entered  during  the  log-on 
procedure.  The  log-on  codes  are  stored  in  files  accessed  by  the  security 
options  in  the  System  Maintenance  modules  of  the  medical  and  industrial 
components.  The  log-on  codes  may  be  changed  through  the  security  options. 

Users  who  are  no  longer  qualified  to  access  NOHIMS  may  be  inactivated. 

Limiting  Access  to  Certain  Functions  by  Passwords.  Password  protection  may 
be  applied  to  any  of  the  modules  in  the  medical  component.  The  system  manager 
may  designate  and/or  change  the  password  at  will  through  the  System  Maintenance 


module.  Access  to  that  password  protected  module  is  restricted  unless  the 
correct  password  is  entered  by  the  user.  This  feature  is  not  invoked  at  the  San 
Diego  test  site,  however.  The  industrial  component  of  NOHIMS  does  not  have  this 
capability. 

Limiting  Access  to  Functions  by  Device.  Both  the  industrial  and  medical 
components  have  a  security  feature  that  limits  access  to  modules  and/or  options 
depending  on  the  device  that  is  being  used  to  access  the  system.  Thus,  access 
at  a  given  terminal  or  printer  can  be  limited  to  any  combination  of  modules  and 
options.  The  list  of  options  that  can  be  accessed  with  each  device  may  be 
specified  and/or  edited  by  the  NOHIMS  system  manager  using  the  security  option 
in  the  system  maintenance  modules.  Actual  data  files  may  only  be  reached  by 
logging  on  to  NOHIMS  with  the  programmer's  access  code.  This  access  may  be 
restricted  for  each  device  by  indicating  whether  the  log-on  sequence  for  the 
device  should  be  in  normal  mode  or  programmer's  mode. 

Time-Outs .  In  each  component,  if  a  command  is  not  received  by  the  terminal 
within  a  predetermined  time  period  (for  example,  60  seconds)  NOHIMS  will  "back- 
out  one  level  in  the  option  driver.  This  backing-out  process  continues  until 
the  system  is  exited.  The  purpose  of  this  feature  is  to  hinder  unauthorized 
access  to  NOHIMS  if  the  terminal  is  left  unattended  for  an  extended  period  of 
time.  However,  if  the  user  has  proceeded  deep  enough  into  the  system,  such  as 
to  the  Directory  Edit  option  in  the  medical  component,  this  time-out  feature 
will  not  be  invoked. 

Scrambled  Identification  Codes.  NOHIMS  does  not  have  scrambled 
identification  codes.  Instead,  during  log-on,  the  user's  identification  code 
either  is  masked  over  with  symbols  on  a  printing  terminal  or  not  shown  at  all  on 
a  video  terminal  to  preserve  the  integrity  of  the  log-on  codes. 

Separate  Files  for  Personnel  Information  and  Medical  Information.  The 
industrial  component  and  the  medical  component  reside  in  different  partitions 
on  the  mainframe  called  UCIs.  All  data  files  and  security  files  (containing 
user  identification  codes,  device  tables,  etc.)  are  kept  separately  in  these  two 
UCIs.  Users  of  the  industrial  component  may  not  access  the  medical  database  or 
the  medical  modules  from  the  industrial  component  UCI.  The  medical  component 
has  an  OCCUPATIONAL  HEALTH  INFORMATION  option  in  the  main  option  driver  that  was 
intended  to  provide  access  to  the  industrial  component;  however,  this  link  has 
not  been  established  yet.  Currently,  a  medical  component  user  is  required  to 
back-out  of  the  medical  component  UCI  and  log-on  to  the  industrial  component  UCI 
in  order  to  access  the  industrial  component.  In  practice,  the  medical  users  do 
not  have  access  codes  for  the  industrial  component  and,  therefore,  do  not  access 
the  industrial  component. 

The  only  existing  interfaces  between  the  industrial  component  and  the 
medical  component  are  part  of  the  PATIENT  SUMMARY  option  in  the  Display  Medical 
Data  module  of  the  medical  component  and  the  MOVE  SSNS  FROM  INDUS  UCI  option  in 
the  COSTAR  Report  Generator  module  of  the  medical  component.  The  PATIENT 
SUMMARY  option  displays  current  exposure  data  from  the  industrial  component  for 
the  patient  selected.  The  exposure  data  are  obtained  from  a  special  global  in 
the  industrial  UCI  that  is  separate  from  the  industrial  database  globals.  The 
MOVE  SSNS  FROM  INDUS  UCI  option  accesses  the  same  special  global  and  copies  a 
series  of  worker  Social  Security  Numbers  into  a  special  global  in  the  medical 
component.  This  latter  function  is  part  of  a  series  of  five  options  designed  to 
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generate  data  for  use  by  the  Naval  Health  Research  Center.  The  operational  site 
users  will  not  have  access  to  these  options. 


Masked  Fields.  NOHIMS  does  not  use  masked  fields  in  the  data  files.  The 
developers  considered  the  other  NOHIMS  logical  security  controls  to  be 
sufficient  to  protect  the  database. 

NOHIMS  has  four  other  logical  security  features  that  were  not  described  in 
the  NOHIMS  SDP. 

Limiting  Access  to  Functions  by  Class  of  User/Identification  Code  of  the 
jlser.  In  the  medical  component  of  NOHIMS,  the  system  manager  may  specify  and/or 
change  the  modules  and/or  options  that  a  particular  class  of  users  may  access. 
For  example,  personnel  not  involved  in  data  entry  may  be  limited  to  display  and 
retrieval  functions,  and  access  to  important  functions  such  as  the  System 
Maintenance  module  may  be  limited.  The  industrial  component  goes  to  one  more 
level  of  specificity  and  allows  the  system  manager  to  limit  access  to  modules 
and/or  options  for  each  individual  user,  rather  just  a  class  of  users. 

Interplay  of  Access  Limitations  by  Device  and  by  Class  of 
User/Identif ication  Code  of  User~]  The  access  specifications  for  a  given  user 
and  the  device  currently  being  used  are  combined  to  determine  the  modules  and/or 
options  that  may  be  accessed  by  that  user  using  that  device.  Only  those  modules 
and/or  options  that  are  allowed  for  both  the  user  and  the  device  will  be 
accessible. 

Confidentiality  Warnings.  The  Encounter  Report  and  Patient  Summary 
produced  by  the  medical  component  of  NOHIMS  either  display  or  print  the 
confidentiality  warning  "FOR  OFFICAL  USE  ONLY.  Data  Contained  Herein  Are 
Subject  to  the  Privacy  Act  of  1974." 

Interrupt  Trap.  NOHIMS  options  in  the  medical  component  that  run  for  long 
periods  of  time  may  be  interrupted  by  the  user.  These  functions  have  an 
interrupt  trap  that  will  return  the  user  to  the  system  option  menu  if  the 
function  is  interrupted.  This  security  feature  prevents  the  user  from  falling 
out  of  NOHIMS  into  the  operating  system.  None  of  the  processes  in  the 
industrial  component  may  be  interrupted  and  so  this  feature  is  not  needed  in  the 
industrial  component. 

Error  Trap.  Both  the  industrial  and  medical  components  have  extensive 
error  trapping  mechanisms.  If  a  program  error  occurs,  the  error  is  recorded  in 
one  of  the  NOHIMS  error  logs  and  the  user  is  returned  to  a  system  option  menu. 
These  traps  prevent  inadvertent  access  to  the  operating  system. 


NOHIMS  Physical  Security  Features 

NOHIMS  physical  security  as  outlined  in  the  SDP  includes  cipher  locks  on 
doors,  a  log  book  for  people  entering  the  computer  room,  and  a  record  of  batch 
programs.  Currently,  the  mainframe  PDF  11/24  on  which  NOHIMS  resides  for  the 
San  Diego  test  site  is  located  at  the  Naval  Health  Research  Center  (NHRC). 

There  are  cipher  locks  on  the  door  to  the  computer  room  at  NHRC.  However,  they 
do  not  keep  a  log  book  of  noncomputer  personnel  entering  the  room  nor  do  the 
rooms  that  contain  terminals  and  printers  connected  to  the  PDP  have  cipher 
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locks.  At  the  North  Island  test  site,  neither  the  Occupational  Health  Unit  nor 
the  Industrial  Hygiene  Division  rooms  that  contain  the  terminals  and  printers 
[  have  cipher  locks.  At  Bremerton,  the  door  to  the  room  that  contains  the  Plessey 

|  mainframe  has  cipher  locks.  There  is  no  log  book  for  people  entering  this 

|  computer  room.  As  no  batch  programs  are  run  for  NOHIMS,  the  third  physical 

security  feature  is  not  applicable  to  either  site. 


Summary 


NOHIMS  has  all  of  the  logical  security  features  that  were  described  in  the 
SDP  except  for  one.  NOHIMS  limits  access  to  certain  functions  by  password  and 
limits  access  to  files  by  device.  It  has  passwords  to  log-on,  time-outs  at 
system  prompts,  concealed  identification  codes,  and  separate  files  for  personnel 
and  medical  information.  It  does  not  store  data  using  masked  fields.  In 
addition,  NOHIMS  limits  access  to  functions  by  class  of  user  in  the  medical 
component  and  by  individual  user  in  the  industrial  component.  It  also  has 
interplay  between  the  access  limitations  by  device  and  the  access  limitations  by 
class  of  user/identif ication  code  of  user,  confidentiality  warnings  on  medical 
displays/reports,  and  interrupt  traps  and  extensive  error  trapping  to  prevent 
inadvertent  access  to  the  operating  system. 


Access  to  the  two  NOHIMS  mainframes  is  limited  by  cipher  locks  on  the  doors 
to  the  computer  rooms.  Cipher  locks  are  not  used  on  rooms  containing  printers 
and  terminals  at  the  San  Diego  test  site.  Neither  test  site  uses  log  books  to 
record  entry  of  noncomputer  personnel  to  the  computer  room.  Records  of  batch 
programs  are  not  applicable  to  NOHIMS. 


Evaluation  of  Adequacy  of  Security  Features 

We  asked  three  NtIRC  NOHIMS  developers,  seven  higher  level  Navy  managers, 
six  medical  care  providers,  five  industrial  hygienists,  and  two  system  managers 
to  assess  the  adequacy  of  NOHIMS  security  features.  (One  system  manager  has 
been  categorized  as  both  an  NHRO  NOHIMS  developer  and  as  a  system  manager  in 
this  evaluation.  He  was  counted  as  a  system  manager  for  the  purposes  of  this 
section.)  We  questioned  the  interviewees  about  the  adequacy  of  certain  security 
features,  to  what  decree  in  their  opinion  t he  security  features  are  being 
utilized,  how  sufficient  the  security  protection  provided  by  NOHIMS  is,  areas  of 
protection  that  are  Jacking,  and,  lastly,  whether  the  security  protection 
provided  by  NOHIMS  is  necessary.  Component  13  of  Appendix  A  contains  the 
questions  that  we  used  for  this  portion  of  the  evaluation.  In  general,  the 
tables  show  that  a  large  number  of  people  made  no  comment  for  each  question. 

Many  of  these  people  felt  that  they  did  not  know  the  feature  well  enough  to 
comment. 

Table  27  presents  the  respondents'  assessment  of  the  adequacy  of  sign- 
on/off  procedures  to  prevent  unauthorized  access  to  NOHIMS.  Sixty-five  percent 
of  those  who  responded  to  this  question  felt  that  the  protection  provided  by  the 
sign-on/off  procedures  (including  the  log-on  identification  code)  were  adequate 
or  very  adequate  to  prevent  unauthorized  access  to  NOHIMS.  Two  higher  level 
managers  (14 %  of  the  respondents)  gave  NOHIMS  a  somewhat  adequate  rating,  one 
medical  care  provider  (7%)  gave  NOHIMS  a  somewhat  inadequate  rating,  and  one 
higher  level  manager  and  one  industrial  hygienist  (14%)  gave  NOHIMS  a  rating  of 
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very  inadequate  with  regard  to  the  sign-on/off  procedures.  Both  the  higher 
level  manager  and  the  industrial  hygienist  who  gave  the  sign-on/off  procedures  a 
rating  of  very  inadequate  felt  that  not  enough  characters  were  used  in  the  log¬ 
on  identification  codes.  NOHIMS  allows  identification  codes  of  from  three  to 
five  characters.  Most  of  the  codes  used  at  the  test  sites  are  just  three 
characters.  An  industrial  hygienist  at  Bremerton  commented  that  he  likes  the 
identification  codes.  Two  individuals  expressed  concern  that  anyone  who  wishes 
can  gain  access  to  the  system.  One  of  these  people,  a  higher  level  manager, 
felt  that  there  was  a  need  to  "increase  the  sign-on/off  feature  somehow,"  but 
did  not  have  specific  improvements  in  mind. 

An  NHRC  NOHIMS  developer  raised  two  security  issues  that  relate  more  to 
"database  integrity  protection  issues  than  confidentiality  issues."  He  saw  a 
potential  for  misuse  of  the  MUMPS  operating  system  via  the  programmer’s  access 
code  and  problems  with  MUMPS  itself.  For  example,  he  thought  that  an  interrupt 
in  the  Interactive  Query  of  the  industrial  component  could  exit  the  user  to 
programmer's  mode  rather  than  a  system  menu.  The  contracted  NOHIMS  developer 
reports  that  the  Interactive  Query  cannot  be  interrupted,  however. 

Table  28  shows  the  interviewees'  assessment  of  the  adequacy  of  the  various 
security  levels  in  NOHIMS  (by  device,  by  user  identification  code  or  user 
classification,  and  through  passwords  for  specific  options)  to  prevent 
unauthorized  access  to  NOHIMS.  A  large  number  of  the  interviewees  were  not 
aware  of  these  NOHIMS  security  features  and,  therefore,  could  not  assess  their 
adequacy.  Of  those  who  rated  the  adequacy  of  these  NOHIMS  features,  nine  (90%) 
felt  that  these  various  security  levels  were  very  adequate  or  adequate  to 
prevent  unauthorized  access  to  NOHIMS.  One  higher  level  manager  (10%  of  all 
respondents)  gave  NOHIMS  a  rating  of  somewhat  inadequate  in  this  area,  although 
he  did  not  explain  why.  An  NHRC  NOHIMS  developer  felt  that  the  option  choices 
for  setting  device  and  user  access  limitations  should  be  more  detailed.  For 
example,  access  to  Survey  Data  should  be  broken  down  into  access  to  Survey  Data 
and  to  Environment  Data  since  NOHIMS  may  automatically  allow  the  user  access  to 
Environment  Data  from  the  Survey  Data  option. 

Only  three  interviewees  commented  on  the  adequacy  of  the  confidentiality 
warnings  on  the  medical  input  and  output  documents  to  maintain  the 
confidentiality  of  patient/worker  data.  The  rest  of  the  interviewees  had  not 
seen  the  warning  messages  (see  Table  29).  Two  of  the  respondents  thought  that 
the  confidentiality  warnings  were  very  adequate  and  one  thought  that  they  were 
somewhat  adequate.  The  system  manager  who  rated  the  adequacy  of  the 
confidentiality  warnings  stated  that  they  "met  Navy  regulations."  The  NHRC 
NOHIMS  developer  who  assessed  the  adequacy  of  the  messages  felt  that  they  should 
be  on  the  Individual  Exposure  Examination  Report  as  well  as  on  the  medical 
component  reports. 

We  next  asked  the  NHRC  NOHIMS  developers,  medical  care  providers, 
industrial  hygienists,  and  system  managers  to  what  degree  the  security 
protection  features  provided  by  NOHIMS  are  utilized  at  the  test  sites.  Of  the 
seven  people  who  responded  to  this  question,  six  (86%)  thought  that  the  features 
were  fully  utilized  (see  Table  30).  The  system  manager  at  the  Bremerton  test 
site  thought  that  the  utilization  of  the  features  was  "somewhere  between  fully 
and  loosely  utilized."  One  industrial  hygienist  at  Bremerton  commented  that 
"everyone  knows  each  other's  ID  code,"  although  he  did  not  seem  to  feel  that 
this  has  presented  any  security  problems. 
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Table  31  presents  the  interviewees’  general  assessment  of  the  sufficiency 
of  NOHIMS  security  protection.  Seventy  percent  of  those  who  rated  the  general 
sufficiency  of  the  NOHIMS  security  protection  gave  NOHIMS  a  rating  of 
sufficient.  One  medical  care  provider  (6%  of  the  respondents)  gave  NOHIMS  a 
rating  of  somewhat  sufficient.  Two  users  (12%)  said  that  the  security 
protection  was  somewhat  insufficient  and  two  users  (12%)  felt  that  the 
protection  was  insufficient.  A  medical  care  provider  commented  that  "physical 
security  is  lacking"  and  that  "codes  are  too  easy  to  figure  out  since  people's 
initials  are  used."  A  system  manager  reported  that  the  ID  codes  print  on  some 
printers  that  do  not  recognize  a  backspace  character.  An  industrial  hygienist 
reported  that  some  terminals  do  not  always  time-out  if  left  unattended.  Another 
industrial  hygienist  felt  that  the  identification  codes  should  contain  more 
characters.  A  higher  level  manager  also  felt  that  the  sign-on  codes  had  too  few 
characters.  Another  higher  level  manager  expressed  concern  over  inadequate 
sign-on/off  procedures  and  the  physical  accessibility  of  the  system. 

Nearly  all  of  the  interviewees  heartily  agreed  that  the  security  protection 
provided  by  NOHIMS  is  necessary  because  of  the  sensitive  nature  of  the  medical 
data  (see  Table  32).  One  higher  level  manager  commented  that  database  security 
is  an  "important  issue  with  workers  [in  order]  to  keep  their  confidence  [in 
NOHIMS]."  The  medical  care  provider  who  gave  an  "other"  rating  to  this  question 
felt  that  all  of  the  security  features  were  very  appropriate,  but  that  the 
protection  is  "probably  too  much  if  medical  care  providers  are  limited  by 
class." 

Summary 

Sixty-five  percent  of  the  respondents  felt  that  the  NOHIMS  sign-on/off 
procedures  are  adequate  or  very  adequate  to  prevent  unauthorized  access  to 
NOHIMS.  Four  people  felt  that  the  sign-on  procedures  should  be  augmented  in 
some  fashion,  however.  Two  of  these  people  felt  that  the  sign-on  identification 
codes  should  have  more  characters.  Ninety  percent  of  the  interviewees  who  rated 
the  adequacy  of  the  various  security  levels  in  NOHIMS  felt  that  they  were 
adequate  or  very  adequate  to  prevent  unauthorized  access  to  NOHIMS.  A  large 
number  of  the  people  interviewed  were  not  even  aware  of  these  features,  however. 
Only  three  people  commented  on  the  adequacy  of  confidentiality  warnings  in  the 
medical  input  and  output  documents.  All  three  respondents  thought  that  they 
were  somewhat  to  very  adequate.  The  NOHIMS  security  protection  features  are 
pretty  much  fully  utilized  at  the  test  sites,  although  ID  codes  are  not  kept 
strictly  secret.  Seventy  percent  of  those  who  rated  the  general  sufficiency  of 
the  NOHIMS  security  protection  felt  that  it  was  sufficient.  Areas  of  weakness 
that  were  mentioned  included  the  nature  of  the  log-on  identification  codes  and 
physical  security  controls.  All  but  one  interviewee  agreed  that  the  security 
protection  provided  by  NOHIMS  is  necessary. 


DESCRIPTION  OF  HARDWARE  AND  SOFTWARE  SUPPORT  REQUIREMENTS 

The  following  describes  the  hardware  and  software  support  requirements  for 
NOHIMS. 
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TABLE  32 


Category  added  by  respondent 


Currently  in  San  Diego,  NOHIMS  resides  on  a  Digital  Equipment  Corporation 
PDP  11/24  located  at  the  Naval  Health  Research  Center  (NHRC).  NHRC  personnel 
estimate  that  they  have  required  a  system  manager  two  hours  per  week  (.05  FTE) 
and  an  electronic  technician  four  hours  per  week  (.1  FTE)  to  support  the  system. 
In  addition,  they  have  utilized  one  outside  consultant  on  demand  for 
telecommunication  problems  and  have  maintenance  contracts  with  two  vendors, 
Digital  Equipment  Corporation  (for  the  central  processing  unit)  and  Systems 
Industries  (for  the  disk  packs  and  tape  drive).  These  support  personnel 
presently  perform  a  variety  of  functions  including  installation  and 
configuration  of  hardware,  reconfiguration  of  hardware,  periodic  maintenance, 
weekly  system  back-ups,  repacking  of  disks,  and  repairs.  The  NHRC  NOHIMS 
developers  estimate  that  in  the  future  one  FTE  system  manager,  1  FTE  assistant 
system  manager,  and  one  vendor  for  several  hours  per  month  would  be  able  to 
maintain  NOHIMS  for  the  entire  San  Diego  region. 

In  Bremerton,  NOHIMS  runs  on  a  Plessey  11/23.  Hardware  support  has 
been  provided  through  one  half-time  system  manager  and  a  maintenance  contract 
with  Plessey  Peripherals.  Only  15  hour  per  month  of  the  system  manager's  time 
is  devoted  to  hardware  support,  however.  The  support  functions  that  have  been 
provided  include  periodic  maintenance  and  system  back-ups  which  are  performed 
every  two  weeks. 

In  the  future,  NOHIMS  will  require  long-term  file  maintenance,  record 
archiving  when  disks  become  full,  and  decisions  about  file-disk  set-ups.  The 
frequency  of  these  functions  will  depend  on  the  size  of  the  applications  and 
hardware  constraints. 


Virtually  no  software  support  is  needed  for  the  industrial  component  of 
NOHIMS.  The  internal  integrity  checks  in  the  system  mean  that  NOHIMS  is 
reliable  and  operationally  error-free.  The  industrial  component  does  require 
system  support  by  a  system  manager  to  ensure  that  the  tables  and  directories  are 
kept  up-to-date  and  to  review  the  error  reports.  The  contracted  NOHIMS 
developer  for  the  industrial  component  estimates  that  20  hours  per  month  of 
system  support  (.12  FTE)  will  be  required  to  maintain  each  NOHIMS  site. 

The  medical  component  of  NOHIMS  requires  minimal  ongoing  software  support 
to  fix  software  problems.  During  the  first  months  of  installation  and  operation 
of  the  medical  component,  outside  software  support  was  required  frequently,  but 
now  the  medical  component  operates  relatively  free  of  software  support.  Unless 
changes  or  additions  are  made  to  the  data  collection  forms,  minimal  system 
support  for  the  tables  and  directories  is  required.  A  system  manager  should 
review  the  error  logs  and  start  and  stop  monitor  on  an  at  least  daily  basis 
because  the  error  logs  may  indicate  impending  system  problems.  The  contracted 
NOHIMS  developers  for  the  medical  component  estimate  that  a  minimum  of  20  hours 
per  month  of  system  support  (.12  FTE)  will  be  required  to  maintain  each  NOHIMS 
site.  If  new  versions  of  existing  forms  or  additional  encounter  forms  are 
developed,  the  system  support  (forms  design,  directory  work,  etc.)  to  implement 
these  forms  is  expected  to  be  substantial. 


Summar 


Hardware  short-term  support  functions  for  NOHIMS  include  installation  and 
configuration  of  hardware,  reconfiguration  of  hardware,  periodic  maintenance, 
system  back-ups,  repacking  of  disks,  and  repairs.  Long-term  support 
requirements  include  file  maintenance,  record  archival,  and  decisions  about  file 
disk  set-ups.  The  frequency  of  these  functions  and  the  amount  of  support 
personnel  or  contracts  required  will  depend  on  the  size  of  the  application. 

Very  little  software  support  is  required  to  maintain  the  industrial 
component  of  NOHIMS.  Approximately  20  hours  per  month  of  system  support  will  be 
required  to  maintain  each  NOHIMS  industrial  site.  The  medical  component 
requires  minimal  ongoing  system  support,  unless  changes  or  additions  are  made  to 
the  data  collection  forms.  Again,  approximately  20  hours  per  month  of  basic 
system  support  will  be  required  to  maintain  each  medical  component  site. 


DESCRIPTION  OF  AVAILABLE  SYSTEM  SUPPORT 

NOHIMS  will  require  system  support  in  four  areas:  the  initial  training  of 
NOHIMS  users,  ongoing  and  update  training  of  NOHIMS  users,  NOHIMS  hardware  and 
operating  system  support,  and  NOHIMS  software  support.  The  following  subsection 
discusses  the  resources  that  are  available  for  these  areas  of  NOHIMS  system 
support . 


System  Support  for  Initial  and  Ongoing  Training 

The  system  support  resources  that  will  be  available  for  initial  and  ongoing 
training  in  the  use  of  NOHIMS  include  a  Computer-Aided  Instructional  (CAI) 
module,  the  Navy  Regional  Data  Automation  Center  (NARDAC),  the  COSIAR  Users 
Group  (CUG),  extensive  system  documentation,  and  regional/local  NOHIMS  system 
managers. 

The  Naval  Medical  Research  and  Development  Command  (NMRDC)  under  the 
auspices  of  the  Department  of  Defense  Small  Business  Innovation  Research  program 
recently  funded  R-K  Research  and  System  Design,  Malibu,  California  to  develop  a 
Computer-Aided  Instructional  (CAI)  module  for  NOHIMS.  During  the  first  year  of 
this  contract,  adaptable  instructional  software  will  be  incorporated  into  the 
NOHIMS  CAI  module  for  the  industrial  component.  If  the  contract  is  funded  for  a 
second  year,  the  medical  component  will  be  incorporated  into  the  f'A  f  module  in 
the  second  year.  When  completed,  the  interactive  CAI  module  for  NOHIMS  will  be 
useful  for  both  initial  and  ongoing  training  of  personnel  in  the  use  of  the 
industrial  and  medical  components.  The  module  will  be  geared  for  different 
levels  of  NOHIMS  users  such  as  data  entry  clerks,  system  managers,  industrial 
hygienists,  and  medical  care  providers.  The  CAI  system  will  also  have  features 
that  allow  curriculum  designers  and  training  specialists  to  author,  modify,  and 
maintain  the  NOHIMS  CAI  module. 

Currently,  technical  support  for  NOHIMS  is  provided  by  the  Naval  Health 
Research  Center  (NHRC) ,  San  Diego,  California.  NIIRC,  through  its  own  staff  and 


contractors,  has  provided  some  training  to  the  two  NOHIMS  sites.  When  NOHIMS  is 
installed  at  other  Navy  industrial  sites,  the  Navy  Regional  Data  Automation 
Center  (NARDAC),  Washington,  D.C.  will  be  responsible  for  conducting  on-site 
initial  training  and  subsequent  ongoing  and  update  training.  Presently,  NARDAC 
is  learning  to  implement  and  support  NOHIMS  in  preparation  for  these  upcoming 
endeavors.  In  the  future,  NARDAC  may  wish  to  contract  with  the  original  NOHIMS 
developers  for  assistance  or  support  in  the  training  functions. 

The  COSTAR  Users'  Group  (CUG),  a  national  organization  of  people  involved 
with  COSTAR  (the  basis  for  the  medical  component  of  NOHIMS),  is  another  resource 
for  NOHIMS  training  support.  CUG  provides  a  variety  of  COSTAR  support  services. 
It  distributes  public  domain  documentation  for  COSTAR  along  with  other  brochures 
and  handouts  for  a  nominal  fee.  CUG  also  publishes  The  COSTAR  Times  (a  monthly 
newsletter)  to  keep  CUG  members  informed  of  COSTAR  events  and  developments  and 
distributes  a  list  of  COSTAR  consultants  and  vendors.  In  addition,  CUG  sponsors 
an  annual  series  of  meetings  and  tutorials  in  conjunction  with  the  MUMPS  Users' 
Group  annual  meeting.  This  week-long  meeting  is  held  each  year  at  a  major  city 
in  the  United  States,  alternating  East  Coast,  Midwest,  and  West  Coast  locations. 
The  COSTAR  tutorials  at  the  meeting  cover  both  introductory  material  such  as 
installation  considerations  as  well  as  advanced  topics  including  the  COSTAR 
Report  Generator  and  the  Medical  Query  Language. 

NOHIMS  has  voluminous  system  documentation.  Both  the  medical  and 
industrial  components  have  extensive  operations  and  system  maintenance  manuals 
written  specifically  for  NOHIMS  to  support  and  augment  the  system's  on-line 
assistance  functions.  These  are  the  NOHIMS  Users'  Reference  Manual  and  the 
NOHIMS  System  Manager's  Manual  for  the  medical  component  and  the  NOHIMS  User's 
Guide  and  the  NOHIMS  OHS  System  Maintenance  Manual  for  the  industrial  component. 
These  manuals  explain  the  purpose  of  each  module  of  the  system  and  the  options 
under  each  module.  In  addition,  the  documentation  for  the  medical  component 
contains  examples  of  typical  data  entry  sequences  and  job  aids  that  contain 
lists  of  patient  items  or  codes  that  may  be  referenced  during  data  entry.  The 
job  aids  include  Possible  Patient  Items  in  Registration  and  Data  Items  Specified 
as  Other  (Hazardous  Agent  Surveillance,  Laboratory  Tests,  Radiology,  Problem 
Codes,  and  ICD-9-CM  Diagnoses).  The  manual  also  contains  three  clear  plastic 
overlays  to  be  used  in  entering  data  from  the  Asbestos  Medical  Surveillance 
Program  and  the  Hearing  Conservation  Program.  These  manuals  and  job  aids  will 
be  useful  for  training  by  NARDAC  as  well  as  self-training  of  NOHIMS  users. 

Also,  NARDAC  has  obtained  a  copy  of  the  COSTAR  public  domain  documentation  from 
CUG  for  use  in  training  NOHIMS  users. 

Since  the  Navy  has  frequent  turnover  of  staff  positions,  it  is  essential 
that  a  resource  for  ongoing  support  and  training  be  readily  accessible.  Once  a 
region  (or  site)  has  received  initial  training  in  the  use  of  NOHIMS,  the 
regional  (or  local)  NOHIMS  system  manager  should  be  able  to  support  NARDAC  in 
the  ongoing  training  of  system  users. 


System  Support  for  NOHIMS  Hardware  and  Operating  System 

The  system  support  that  is  required  for  the  NOHIMS  hardware  and  operating 
system  will  depend  greatly  on  the  hardware  and  operating  system  that  are 
selected  for  NOHIMS.  Currently  in  San  Diego,  hardware  and  operating  system 
support  for  NOHIMS  is  provided  through  maintenance  contracts  with  hardware  and 
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operating  system  vendors  (including  technical  hot  lines  to  the  vendors)  and 
support  personnel  at  NHRC.  The  NHRC  NOHIMS  developers  estimate  that  one  full¬ 
time  system  manager,  one  full-time  assistant  system  manager,  and  one  vendor 
contracted  for  several  hours  per  month  will  be  required  to  maintain  NOHIMS  for 
an  entire  region  similar  to  the  San  Diego  region.  In  Bremerton,  hardware 
support  is  provided  for  several  hours  per  month  by  the  system  manager  and 
also  through  a  maintenance  contract  with  the  hardware  vendor.  In  the  future, 
the  Navy  Regional  Data  Automation  Center  (NARDAC)  will  also  be  responsible  for 
providing  hardware  support. 


System  Support  for  NOHIMS  Software 


The  system  support  for  NOHIMS  software  is  presently  being  provided  by  the 
Naval  Health  Research  Center  (NHRC).  When  NHRC  personnel  have  been  unable  to 
troubleshoot  software  problems,  they  have  called  upon  the  NOHIMS  contracted 
developers.  When  NOHIMS  is  installed  at  Navy  industrial  sites  other  than  the 
two  test  sites,  the  Navy  Regional  Data  Automation  Center  (NARDAC),  Washington, 
D.C.  will  provide  the  ongoing  technical  support  for  NOHIMS. 


The  local  system  manager  will  also  be  able  to  provide  some  software  system 
support  through  the  Maintenance  module  in  the  industrial  component  and  the 
Systems  Maintenance  module  in  the  medical  component.  Both  of  the  maintenance 
modules  have  options  that  allow  the  system  manager  to  view  hardware  and  software 
errors  that  have  been  detected  by  the  system.  The  industrial  component  also  has 
an  option  that  performs  integrity  checking  on  the  industrial  component  database 
to  maintain  data  integrity.  Many  of  the  errors  detected  by  this  function  can  be 
automatically  corrected  by  the  system.  The  medical  component  relies  on 
operating  system  utilities  to  test  the  integrity  of  the  database  in  the  event  of 
a  system  crash.  If  data  or  routines  are  lost,  however,  programming  intervention 
from  NARDAC  will  probably  be  required. 


Summary 


The  system  support  resources  that  will  be  available  for  initial  and  ongoing 
training  in  the  use  of  NOHIMS  include  a  Computer-Aided  Instructional  (CAI) 
module,  the  Navy  Regional  Data  Automation  Center  (NARDAC),  the  COSTAR  Users' 
Group  (CUG),  extensive  system  documentation,  and  regional/local  NOHIMS  system 
managers.  Possible  sources  for  hardware  support  include  contracts  with  hardware 
vendors  (many  of  whom  have  technical  hot  lines),  local/regional  system  managers, 
and  NARDAC.  Both  NARDAC  and  the  local  system  managers  will  be  able  to  provide 
system  support  for  the  NOHIMS  software. 


DESCRIPTION  OF  SCENARIOS  TO  MAINTAIN  NOHIMS 

The  scenarios  to  maintain  NOHIMS  fall  into  three  categories:  (1)  prime¬ 
time  system  maintenance  functions,  (2)  off-shift  system  maintenance  functions, 
and  (3)  record  archiving. 


A  NOHIMS  system  manager  must  perform  a  few  tasks  on  a  daily  basis  in  order 
to  maintain  NOHIMS.  Both  the  industrial  and  medical  components  require  that  the 
system  manager  review  the  error  log/error  reports  on  an  at  least  daily  basis. 

If  errors  have  been  detected,  the  system  manager  will  be  required  to  investigate 
or  obtain  assistance  in  investigating  the  source  of  the  error  in  order  to 
resolve  the  problem.  The  review  of  the  error  logs/error  reports  is  an  important 
function  because  the  error  logs  may  indicate  an  impending  system  problem.  in 
the  medical  component,  the  system  manager  must  also  review  the  status  of 
Monitor  (the  caretaker  job  that  manages  filing  transactions)  to  be  certain  that 
it  is  running.  If  Monitor  has  crashed,  the  system  manager  must  restart  the 
Monitor .  The  Monitor  should  also  be  started  and  halted  on  a  daily  basis  to 
allow  the  medical  component  to  perform  housekeeping  chores. 


Off-Shift  System  Maintenance  Functions 


Three  off-shift  system  maintenance  functions  are  required  to  maintain 
NOHIMS.  A  system  image  back-up  of  all  of  the  NOHIMS  routines,  files,  and 
database  should  be  made  to  another  disk  on  a  daily  basis.  This  will  insure  that 
the  most  data  that  would  need  to  be  re-entered  in  the  event  of  a  system  crash 
would  be  one  day's  worth  of  entry.  If  a  NOHIMS  site  has  minimal  entry  to  the 
system,  the  frequency  of  back-ups  could  be  adjusted  downward  accordingly. 
Currently,  the  Naval  Health  Research  Center  (NHRC)  is  making  disk-to-disk  back¬ 
ups  of  each  component  on  a  weekly  basis  and  disk-to-tape  back-ups  on  a  monthly 
basis.  Other  off-shift  tasks  include  repacking  data  disks  periodically  and 
recreating  the  medical  component  alphabetic  directory  on  an  as  needed  basis. 

NHRC  estimates  that  it  has  repacked  NOHIMS  data  disks  every  six  months.  The 
alphabetic  directory  needs  to  be  recreated  if  changes  or  additions  are  made  to 
modifier  short  names. 


Record  archiving  only  needs  to  be  performed  as  often  as  required  to 
maintain  enough  disk  storage  space  for  new  records.  Thus,  it  is  very  dependent 
on  the  hardware  configuration  and  the  size  of  the  application.  Periodic 
repacking  of  data  disks  will  minimize  the  amount  of  record  archiving  that  is 
required.  So  far,  neither  NOHIMS  test  site  has  needed  to  archive  worker/patient 
records.  As  an  alternative  to  record  archiving,  additional  disk  packs  could  be 
purchased  keeping  data  on-line  and  accessible  at  all  times. 


Summan 


Prime-time  system  maintenance  functions  include  at  least  daily  review  of 
error  logs  for  both  components,  and  daily  starting  and  halting  of  Monitor  and 
review  of  the  status  of  Monitor  in  the  medical  component.  Off-shift  system 
maintenance  functions  include  daily  system  back-up  to  disk,  periodic  back-up  to 
tape,  periodic  repacking  of  data  disks,  and  recreation  of  the  medical  component 
alphabetic  directory  as  needed.  Record  archiving  will  need  to  be  performed  when 
data  disks  become  full  unless  additional  disks  are  purchased. 
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DESCRIPTION  OF  ORGANIZATIONAL  REQUIREMENTS 


The  organizational  requirements  for  operation  of  NOHIMS  are  described 
below.  This  discussion  covers  the  degree  of  MUMPS  programming  knowledge  that  is 
required  to  operate  NOHIMS,  the  level  of  comprehension  of  source  code  required, 
a  personnel  staffing  description,  and  requirements  for  installation  area 
configurations. 


MUMPS  Programming  Knowledge 

NOHIMS  users  do  not  need  to  have  any  knowledge  of  the  MUMPS  programming 
language  in  order  to  use  NOHIMS.  Both  the  medical  and  industrial  components  of 
NOHIMS  have  user-friendly  log-on  procedures  and  utilize  option  menus  to  direct 
the  user  through  the  system.  Extensive  intrinsic  on-line  assistance  aids  the 
user  in  operating  the  system. 

The  NOHIMS  system  managers  do  not  need  to  have  programming  skills  to 
perform  the  maintenance  functions  accessible  through  the  system  options.  A 
minimal  amount  of  MUMPS  knowledge  would  be  useful  to  a  system  manager  for 
resolving  some  of  the  minor  system  problems  that  occur,  such  as  freeing  a  busy 
record  in  the  medical  component.  Familiarity  with  MUMPS  global  file  structures 
and  access  to  the  operating  system  manual  would  be  useful  in  deciphering  error 
logs/error  reports. 


NOHIMS  Source  Code  Comprehension 

Comprehension  of  NOHIMS  source  code  is  not  necessary  in  order  to  operate 
NOHIMS.  If  the  system  manager  understands  some  of  the  source  code,  however, 
this  would  be  useful  in  debugging  system  errors  or  in  assisting  technical 
support  in  doing  the  same.  Knowledge  of  NOHIMS  source  code  is  essential, 
however,  if  changes  in  software  functions  not  alterable  through  the  maintenance 
modules  are  required,  or  if  special  input  or  output  conditions  or  pattern 
matches  are  required  for  a  directory  code.  However,  the  software  for  both 
components  is  extremely  complex.  Software  modifications  should  only  be  made  by 
people  who  have  a  thorough  understanding  of  both  MUMPS  and  the  NOHIMS  source 
code.  Changes  should  always  be  made  in  a  test  system  first. 


Personnel  Staffing  Description 

The  staff  required  to  operate  a  NOHIMS  installation  include  data  collection 
personnel,  data  entry  personnel,  system  managers,  and  support  personnel .  At  the 
two  test  sites,  the  data  collection  tasks  were  added  to  the  already  existing 
industrial  hygiene  and  medical  personnel  functions.  This  created  additional 
work  for  both  types  of  personnel.  Currently,  the  medical  personnel  at  the 
Occupational  Health  Unit  (Ollll),  North  Island  are  required  to  maintain  a  dual 
medical  record:  both  the  traditional  paper  chart  and  the  new  NOHIMS  record  are 
required.  Personnel  allocations  for  NOHIMS  sites  will  need  to  take  into  account 
the  additional  work  required  by  NOHIMS. 

Both  the  industrial  and  medical  components  of  NOHIMS  will  require  data 
entry  personnel.  At  present,  the  OIIU  has  one  lull-time  data  entry  clerk,  while 
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the  Bremerton  industrial  component  site  requires  a  half-time  data  entry  clerk. 
The  San  Diego  industrial  component  site  does  not  have  data  entry  personnel  and, 
consequently,  is  behind  on  survey  data  entry.  The  number  of  data  entry 
personnel  required  can  be  determined  using  the  average  number  of  entries  per  day 
at  the  two  test  sites.  A  full-time  data  entry  clerk  could  probably  enter 
data  for  16-24  average-sized  surveys  per  day,  while  the  medical  component  data 
entry  clerk  could  probably  enter  30-40  complete  medical  records  per  day. 

Both  the  industrial  and  medical  components  require  a  local  system  manager 
approximately  20  hours  per  month  for  system  software  support  such  as  error  log 
review.  Even  more  of  the  system  manager's  time  will  be  required  if  he/she 
becomes  involved  in  troubleshooting  hardware  problems,  data  entry  verification, 
ongoing  training,  and/or  data  retrieval  functions  such  as  queries  and  report 
generator  reports.  If  the  hardware  resides  at  the  actual  application  site,  the 
system  manager  will  also  need  several  hours  per  month  to  make  system  back-ups. 

NOHIMS  requires  some  degree  of  support  personnel  to  provide  hardware 
support  and  to  augment  the  system  support  provided  by  the  local  system  manager. 
The  NOHIMS  developers  at  the  Naval  Health  Research  Center  estimate  that  an 
application  such  as  the  San  Diego  region  would  require  one  full-time  system 
manager,  one  full-time  assistant  manager,  and  a  vendor  contracted  for  several 
hours  per  month  to  maintain  NOHIMS.  This  estimate  assumes  that  the  region  has  a 
centralized  host  computer  with  remote  work  stations. 


Installation  Area  Configuration 


The  requirements  for  the  NOHIMS  installation  areas  will  depend  greatly  on 
whether  the  installation  has  a  computer  resident  at  the  application  site  or 
whether  the  central  processing  unit  resides  off-site.  It  will  also  depend  on 
the  hardware  selected.  Issues  that  should  be  considered  in  configuring  the  work 
areas  include  electrical/power  source  requirements  such  as  power  conditioning, 
surge  suppressors,  and/or  battery  back-up;  lighting  requirements;  communications 
requirements  such  as  the  type  of  communication  lines  used;  heating/cooling 
requirements;  space  and  room  requirements  such  as  raised  floors  and  room 
dimensions;  furniture  equipment  requirements;  and  other  requirements  such  as  a 
non-water  fire  suppression  system.  The  installation  should  be  managed  by  the 
hardware  vendor  and  should  comply  with  all  government  and  vendor  requirements. 
Each  hardware  manufacturer  publishes  environment  requirements  such  as  power 
requirements,  air  conditioning  requirements,  and  line  specifications  for  its 
equipment  which  can  be  used  as  guidelines  during  the  installation  process. 


Area  configuration  requirements  should  be  considered  carefully  before 
hardware  installation.  If  these  issues  are  not  adequately  addressed  prior  to 
installation,  deficiencies  in  the  environment  can  lead  to  serious  problems. 

These  performance  problems  may  include  system  downtime  and  database  degradation, 
possibly  resulting  in  loss  of  data  and/or  operating  time. 


Summary 


System  users  and  system  managers  do  not  need  to  have  any  knowledge  of  the 
MUMPS  programming  language  in  order  to  use  NOHIMS;  however,  a  minimal  amount  of 
MUMPS  knowledge  would  be  useful  to  a  system  manager  for  resolving  minor  system 
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errors.  Comprehension  of  MUMPS  source  code  is  not  necessary,  although  again,  a 
system  manager  would  find  a  little  understanding  useful  during  error  debugging. 
Staffing  allocations  at  NOHIMS  sites  should  take  into  account  the  additional 
time  required  by  regular  personnel  to  collect  NOHIMS  data.  Appropriate  numbers 
of  data  entry  personnel,  system  managers,  and  support  personnel  will  also  be 
required  to  operate  a  NOHIMS  installation.  The  number  required  will  depend  on 
the  size  of  the  application  and  the  hardware  configuration  (remote  versus 
centralized,  for  example).  The  installation  area  configuration  will  also 
greatly  depend  on  the  application  size  and  hardware  configuration.  Issues  to  be 
considered  in  planning  the  installation  area  include  electrical/power  source 
requirements,  lighting  requirements,  communications  requirements, 
heating/cooling  requirements,  space  and  room  requirements,  furniture  and 
equipment  requirements,  and  other  requirements.  These  issues  must  be  adequately 
addressed  prior  to  installation  in  order  to  prevent  serious  system  performance 
problems. 


DESCRIPTION  OF  MINIMUM  HARDWARE  REQUIREMENTS 

The  following  describes  the  minimum  hardware  requirements  for  NOHIMS  in 
terms  of  the  host  computer  configuration,  remote  work  station  requirements,  and 
telecommunication  requirements. 


Host  Computer  Configuration 


The  minimum  host  computer  configuration  for  NOHIMS  can  vary  depending  on 
the  size  of  the  NOHIMS  application.  NOHIMS  will  run  on  any  hardware  that  can 
support  multi-user  ANSI  Standard  MUMPS  and  that  has  the  minimum  hard  disk 
requirements  for  the  particular  application.  MUMPS  systems  exist  for  DEC,  Data 
General,  Harris,  Plessey,  Prime,  Tandem,  and  IBM  minicomputers.  MUMPS  systems 
also  exist  for  several  microcomputers  such  as  Tandy,  IBM,  Convergent 
Technologies  (Burroughs/NCR  equivalents),  COMPAQ,  Motorola,  and  Olivetti.  The 
industrial  component  of  NOHIMS  requires  a  minimum  of  a  10K  partition  in  system 
memory  and  5  megabytes  of  hard  disk  storage  in  addition  to  the  basic  memory 
requirements  for  MUMPS.  The  medical  component  requires  a  minimum  of  a  6K 
partition  of  system  memory,  4-8  megabytes  of  hard  disk  storage  for  the  COSTAR 
routines  and  directories  (dependent  on  the  version  of  MUMPS  used),  and  an 
additional  10-40  megabytes  of  disk  storage  for  patient  record  storage  (COSTAR 
uses  approximately  1,000-2,000  bytes  per  encounter  stored).  In  addition,  the 
system  will  require  some  sort  of  back-up  mechanism,  either  a  streaming  cassette 
or  cartridge,  magnetic  tape  drive,  or  removable  disk  packs.  Ideally,  the  system 
would  have  a  combination  of  back-up  mechanisms.  If  NOHIMS  is  run  on  a 
microcomputer,  a  Bernoulli  box  can  also  be  used  for  back-ups.  The  decision  as 
to  whether  dial-up  ports  are  required  will  depend  on  the  type  of  data  lines  used 
to  access  the  system.  The  Telecommunications  Requirements  section  below 
discusses  data  line  requirements  in  further  detail. 

Remote  Work  Station  Description 

At  remote  sites,  the  minimum  configuration  for  running  NOHIMS  would  be  a 
CRT  terminal.  NOHIMS  can  accommodate  a  variety  of  terminal/cursor  types 
including  any  hardcopy  device,  Infoton  standard  or  Vistar  with  number  pad,  dumb 
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terminals,  and  smart  terminals.  NOHIMS  at  this  point  in  time  does  not  support 
terminals  with  split  screen  features.  If  a  softcopy  device  is  chosen  for  a 
remote  site,  the  users  must  also  have  access  to  a  printer  or  printing  terminal 
(with  keyboard)  for  producing  hardcopies  of  reports.  Printing  terminals  are 
useful  as  a  second  device  because  although  they  are  slower  to  operate,  they  can 
serve  as  a  back-up  instrument  for  the  CRT  should  it  fail. 


Telecommunication  Requirements 

Telecommunication  requirements  vary  with  the  hardware  configuration. 
Generally,  remote  sites  within  100  feet  of  the  host  computer  can  be  linked 
directly  by  cable.  Beyond  100  feet,  dedicated  data  lines  or  nondedicated  local 
lines  with  dial-in  capability  would  be  required.  Microwave  circuits  can  also  be 
used;  however,  they  are  usually  more  costly.  If  utilization  will  be  low,  local 
nondedicated  lines  with  modems  at  either  end  will  probably  be  adequate. 

Dedicated  lines  (point-to-point  circuits)  would  be  a  better  choice  if 
utilization  will  be  high  or  if  there  will  be  several  simultaneous  users.  A 
multiplexor  can  be  connected  to  a  dedicated  line  to  allow  multiple  users  on  the 
same  line. 

With  either  type  of  communication  line,  a  single  connection  can  be  used  to 
alternately  link  two  devices  if  a  Y- junction  (sometimes  called  a  printer 
selector  switch)  is  used.  The  users  determine  which  device  is  to  be  connected 
to  the  computer  by  flipping  the  switch. 

Summary 

The  minimum  host  computer  configuration  for  NOHIMS  varies  depending  on  the 
size  of  the  application.  Minimum  requirements  include  a  central  processing  unit 
with  I6K  of  system  memory  in  addition  to  the  memory  requirements  for  MUMPS,  a 
hard  disk  drive  and  disk  pack  with  20-55  megabytes  of  storage,  and  a  back-up 
mechanism  such  as  a  streaming  cassette  or  cartridge,  magnetic  tape  drive,  or 
removable  disk  packs.  A  remote  site  requires  a  minimum  of  one  CRT  terminal.  A 
printing  terminal  (with  keyboard)  would  also  be  useful.  Remote  sites  will 
require  access  to  at  least  one  local  line  or  one  dedicated  data  line.  If  local 
telephone  lines  are  used,  a  dial-up  port  on  the  host  computer  and  a  modem  at 
each  end  of  the  line  will  be  necessary. 


EVALUATION  OF  THE  SUITABILITY  OF  NOHIMS  TO  NAVY  INFORMATION  PROCESSING  NEEDS 

We  investigated  the  suitability  of  NOHIMS  to  Navy  information  processing 
needs  in  three  areas:  information  collection,  information  retrieval,  and 
information  manipulation.  We  interviewed  the  four  Naval  Health  Research  Center 
(NHRC)  NOHIMS  developers,  seven  higher  level  managers,  five  industrial 
hygienists,  and  six  medical  care  providers  using  the  interview  guide  on 
suitability  found  in  Appendix  A,  Component  19.  The  Bremerton  system  manager  was 
also  inadvertently  asked  this  series  of  questions.  We  included  his  results  with 
the  industrial  hygienists  as  his  comments  were  useful  and  relevant  to  his 
collateral  position  as  an  industrial  hygienist. 


The  questions  we  asked  attempted  to  elicit  the  respondents’  assessment  of 
the  suitability  of  NOHIMS  to  Navy  information  collection,  information  retrieval, 
and  information  manipulation  needs,  and  an  overall  assessment  of  the  adequacy  of 
NOHIMS  for  Navy  information  processing  needs.  In  addition,  we  solicited 
comments  on  areas  of  NOHIMS  that  required  changes  to  make  it  more  suitable  for 
Navy  needs. 

Four  of  the  medical  care  providers  did  not  respond  to  the  questions  on  the 
assessment  of  suitability  of  NOHIMS  because  we  were  running  short  of  time  and  we 
felt  that  other  questions  were  more  important  for  them  to  answer.  We  did  ask 
the  medical  care  providers  to  indicate  if  there  were  changes  that  were  required 
to  make  the  system  more  suitable,  and  what  their  overall  assessment  of  the 
adequacy  of  NOHIMS  for  Navy  information  processing  needs  was. 


Table  33  shows  that  100  percent  of  those  who  assessed  the  suitability  of 
NOHIMS  for  Navy  information  collection  needs  thought  that  NOHIMS  was  very 
suitable.  Currently,  NOHIMS  either  collects  or  is  planned  to  collect  data  in 
the  following  six  categories. 

•  Personnel  data 

•  Hazardous  materials  characteristics 

•  Presence  of  hazardous  materials 

•  Data  on  health  of  workers 

Illness  and  injuries  (planned) 

Routine  examinations 
Test  and  procedure  results 
Medical  histories  (planned) 

•  Individual  exposures  and  exposure  histories 

•  Occupational  histories  (planned) 

Table  34  contains  the  categories  of  additional  data  that  respondents  would 
like  to  see  collected  in  order  to  make  NOHIMS  more  suitable  for  Navy  information 
collection  needs.  The  most  frequently  mentioned  category  is  data  relating  to 
accidents  and/or  incidents  which  was  mentioned  by  43  percent  of  those 
interviewed.  Currently,  these  data  are  not  being  gathered  by  NOHIMS,  although 
the  developers  intended  that  these  data  be  collected.  Environmental  accidents 
and  incidents  may  be  stored  in  the  industrial  component  of  NOHIMS  by  defining 
the  accident  or  incident  as  an  environment  (such  as  "May  1  spill  of  agent  X") 
and  assigning  personnel  affected  by  the  accident  or  incident  to  the  environment. 
The  industrial  hygienists,  however,  have  not  been  trained  to  use  NOHIMS  in  this 
manner. 

In  order  of  frequency  of  mention,  occupational  history  data,  illness  and 
injury  data,  and  medical  history  data  are  the  next  throe  types  of  additional 
data  required  in  order  to  make  NOHIMS  more  suitable  according  to  the 
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TABLE  33 

Assessment  of  Suitability  of  NOHIMS  to  Navy  Information  Collection  Needs 

(Number  who  mentioned  rating) 


NHRC  Higher  Medical  %  of 

NOHIMS  Level  Care  Industrial  Total  Who 

Developers  Managers  Providers  Hygienists  TOTAL  Answered 


Very  suitable 


Somewhat  suitable 


Somewhat 

unsuitable 


Very  unsuitable 


TOTAL  WHO  ANSWERED 


No  Comment 


TOTAL  INTERVIEWED 


'  '  ' 


TABLE  34 

Additional  Information  Collection  Categories  Required 
(Number  who  mentioned  category;  multiple  answers  allowed) 


NHRC  Higher  Medical  %  of 

NOHIMS  Level  Care  Industrial  Total 

Developers  Managers  Providers  Hygienists  TOTAL  Interviewed 

Accidents/ 

incidents 

(not  implemented)  4  3  1  2  10  43 

Occupational 

history 

(planned)  4  3  1  1  9  39 


Illness  and 
injury  data 

(planned)  2  5 

Medical 

history 

(planned)  3  2 

Sick  leave/ 

absenteeism  1  3 

Mortality  data  2  2 

Ventilation 

data  0  1 

More  materials 

inventory  1  1 


1  1  9 

1  1  7 

1  1  6 

1  0  5 

0  1  2 

0  0  2 


39 


i 


30  * 

I 

I 


26 


\ 


22 

9 


i 


9 


Automated 
entry  of 
medical  test 

results  0010 


4 


f 

< 

) 


TOTAL  ■; 

INTERVIEWED  4  7  6  6  23  J 

i 

I 
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respondents.  These  categories  were  mentioned  by  39  percent,  39  percent,  and  30 
percent  of  the  respondents,  respectively.  Although  each  of  these  types  of  data 
were  planned  as  a  part  of  NOHIMS,  as  of  the  time  that  we  evaluated  the  system 
they  had  not  yet  been  implemented.  Since  NOHIMS  is  a  directory-driven  system, 
medical  encounters  for  injury  and  illness  care  may  be  input  to  the  system  if 
data  collection  instruments  and  directory  codes  are  created.  As  part  of  the 
implementation,  lengthy  encounter  forms  were  developed  and  codes  were  added  to 
the  NOHIMS  directory  for  the  occupational  and  medical  histories.  Implementation 
of  these  forms  is  awaiting  approval  of  the  forms  by  other  medical  care  providers 
and  final  testing  of  the  forms. 

Two  other  types  of  required  data  that  were  mentioned  by  the  interviewees 
included  sick  leave  or  absenteeism  data  and  mortality  data  which  were  mentioned 
by  26  percent  and  22  percent  of  those  interviewed,  respectively.  There  is  no 
plan  to  include  either  of  these  types  of  data  in  NOHIMS  at  this  time.  Adding 
ventilation  data,  additional  materials  inventory  data,  and  automated  entry  of 
medical  test  results  were  also  mentioned,  but  by  only  two  or  fewer  of  the 
respondents.  Comments  regarding  the  material  inventory  data  were  that  more 
materials  should  be  added  to  the  inventory  and  that  all  of  the  information  on 
the  Material  Safety  Data  Sheet  should  be  included  in  the  database.  Also, 
distinctions  should  be  made  between  hazards  (e.g.,  benzene)  and  materials  (e.g., 
cleaning  fluid). 

The  respondents  made  several  other  notable  comments  in  regard  to  the 
suitability  of  NOHIMS  for  Navy  information  collection  needs.  One  NHRC  NOHIMS 
developer  stated  that  while  the  data  were  suitable  for  medical  and  industrial 
hygiene  purposes,  it  was  not  suitable  for  safety  purposes.  An  industrial 
hygienist  commented  that  "NOHIMS  has  made  the  Navy  improve  its  information 
collection  and  [has  made  it]  standardize  what  is  collected."  Another  industrial 
hygienist  brought  up  the  issue  of  access  to  the  medical  database  at  this  point 
in  the  interviews.  NOHIMS  collects  certain  medical  data  that  the  industrial 
hygienist  would  like  to  see.  However,  since  industrial  hygienists  have  not  been 
given  access  to  the  medical  component  of  NOHIMS,  the  data  are  not  readily 
available  for  use.  A  higher  level  manager  feels  that  NOHIMS  is  "an  excellent 
tool  for  the  Navy  Asbestos  Medical  Surveillance  Program."  Finally,  one  of  the 
medical  care  providers  commented  that  "[the  NOHIMS]  database  is  very  thorough 
and  professional  [but]  at  the  expense  of  more  forms." 


Navy  Information  Retrieval  Needs 

In  Table  35,  we  see  that  72  percent  of  those  who  evaluated  the  suitability 
of  NOHIMS  for  Navy  information  retrieval  needs  thought  that  NOHIMS  was  very 
suitable.  One  person  (6%  of  respondents)  gave  NOHIMS  a  rating  of  suitable, 
while  four  people  (22%)  rated  NOHIMS  as  somewhat  suitable  for  Navy  information 
retrieval  needs.  The  respondents  who  gave  NOHIMS  a  somewhat  suitable  rating 
felt  that  NOHIMS  was  "lacking  in  some  areas”  of  data  retrieval  capabilities. 

The  respondents  suggested  a  variety  of  information  retrieval  needs  that  if 
met  would  make  NOHIMS  more  suitable  for  Navy  needs.  Table  36  contains  a  list  of 
the  needs  that  the  interviewees  identified  by  user  category.  Within  a  category 
usually  one,  and  at  most  two,  of  those  in  the  category  mentioned  the  need.  None 
of  the  suggestions  were  made  consistently  through  or  across  groups  of 
respondents  with  the  exception  of  t ho  ability  to  retrieve  historical  exposure 
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TABLE  35 

Assessment  of  Suitability  of  NOHIMS  to  Navy  Information  Retrieval  Needs 

(Number  who  mentioned  rating) 

NHRC  Higher  Medical  %  of 

NOHIMS  Level  Care  Industrial  Total  Who 

Developers  Managers  Providers  Hygienists  TOTAL  Answered 


Very  suitable  1  6  1  5  13  72 

Suitable*  1  000  16 

Somewhat 

suitable  2  1  0  1  4  22 

Somewhat 

unsuitable  0  0  0  0  0  0 

Very  unsuitable  0  0  0  0  0  0 


TABLE  36 

Information  Retrieval  Needs 
(Mentioned  once  unless  otherwise  noted) 

NHRC  NOHIMS  Developers 

•  Generate  encounter  forms  from  data  items 

•  More  management  reports 

•  Links  between  medical  and  exposure  data  (two  mentions) 

•  Retrieval  of  historical  exposure  data 

•  Tickler  list  of  environmental  surveys  to  be  done 

Higher  Level  Managers 

•  Spreadsheet  capability 

•  Medical  reports  in  standard  Navy  format 

•  Letters  of  referral  to  physicians 

•  Provide  patient  summary  to  worker 

Medical  Care  Providers 

•  Assistance  with  creating  and  generating  reports 

•  Retrieval  of  historical  exposure  data 

Industrial  Hygienists 

•  User-defined  report  formats 

•  Graphics  capability 

•  Ability  to  retrieve  data  by  testing  variable 
values  in  industrial  component 

•  Retrieval  of  historical  exposure  data 

•  Expanded  word  processing  for  generating 
narrative  reports 

•  Additional  training  in  retrieval  capabilities 
(two  mentions) 


data.  This  need  was  mentioned  by  one  NHRC  NOHIMS  developer,  one  industrial 
hygienist,  and  one  medical  care  provider. 


Other  suggestions  by  the  NHRC  NOHIMS  developers  included  the  following. 

One  developer  would  like  to  be  able  to  automatically  generate  encounter  forms 
from  the  data  items  in  the  NOHIMS  directories.  There  was  one  mention  each  that 
NOHIMS  should  produce  more  management  reports  and  produce  a  tickler  list  of 
environmental  surveys  to  be  conducted.  Two  developers  mentioned  that  NOHIMS 
needs  to  be  able  to  link  exposure  and  medical  data.  Presently,  one  NOHIMS 
feature  retrieves  laboratory  test  and  physical  examination  results  for  selected 
individuals.  The  selection  criteria  may  include  either  exposure  or  medical  data 
items.  Another  NOHIMS  function  prints  exposure  data  from  the  industrial 
component  in  the  Patient  Data  Sheet  in  the  medical  component.  These  developers 
felt  that  more  capabilities  such  as  these  should  be  developed. 

The  higher  level  managers  noted  four  changes  to  make  NOHIMS  more  suitable 
for  Navy  information  retrieval  needs.  A  spreadsheet  capability,  medical  reports 
produced  in  standard  Navy  format,  ability  to  produce  letters  of  referral  to 
physicians,  and  production  of  some  sort  of  a  patient  summary  for  the  worker  at 
the  end  of  the  physical  examination  were  each  mentioned  once  by  the  managers. 

Medical  care  providers  made  two  suggestions  for  improving  the  suitability 
of  NOHIMS.  One  provider  requested  the  ability  to  retrieve  historical  exposure 
data  and  another  would  like  assistance  with  creating  and  generating  reports. 

The  medical  care  provider  who  mentioned  this  last  need  stated  that  "no  one  was 
bridging  the  gap  from  input  to  how  to  get  it  out  to  help  count  beans." 

Finally,  the  industrial  hygienists  felt  there  were  several  changes  that 
could  be  made  to  make  NOHIMS  more  suitable  to  Navy  needs.  They  requested  user- 
defined  formats  for  reports,  a  graphics  capability,  retrieval  of  historical 
exposure  data,  expanded  word  processing  for  generating  narrative  reports,  and 
the  ability  to  retrieve  data  by  testing  variable  values  in  the  industrial 
component.  In  addition,  two  of  the  industrial  hygienists  requested  additional 
training  in  NOHIMS'  existing  information  retrieval  capabilities,  especially  the 
Query/Report  module  in  the  industrial  component. 

Navy  Information  Manipulation  Needs 

Table  37  shows  the  respondents'  ratings  of  the  suitability  of  NOHIMS  to 
Navy  information  manipulation  needs.  Seventy-three  percent  of  the  respondents 
rated  NOHIMS  as  very  suitable  or  suitable.  The  other  27  percent  gave  NOHIMS  a 
somewhat  suitable  rating.  The  NHRC  NOHIMS  developers  and  industrial  hygienists 
thought  that  NOHIMS  was  less  suitable  for  Navy  manipulation  needs  than  the 
higher  level  managers  and  the  medical  care  providers  did.  All  of  the  higher 
level  managers  and  medical  care  providers  gave  NOHIMS  a  very  suitable  rating, 
while  half  of  the  NHRC  NOHIMS  developers  and  industrial  hygienists  gave  NOHIMS  a 
somewhat  suitable  evaluation. 

The  major  criticisms  of  NOHIMS'  data  manipulation  capabilities  were  that 
NOHIMS  needs  "a  fuller  capability  to  manipulate  data.... and  needs  more  complex 
and  sophisticated  techniques  [for  data  analysisj."  Table  38  presents  the 
additional  data  manipulation  capabilities  that  the  interviewees  mentioned.  Four 
of  the  15  persons  (27%)  who  assessed  the  data  manipulation  capabilities  of 


TABLE  37 

Assessment  of  Suitability  of  NOHIMS  to  Navy  Information  Manipulation  Needs 

(Number  who  mentioned  rating) 


NHRC 

NOHIMS 

Developers 

Higher 

Level 

Managers 

Medical 

Care 

Providers 

Industrial 

Hygienists 

TOTAL 

%  of 

Total  Who 
Answered 

Very  suitable 

1 

6 

1 

2 

10 

67 

Suitable* 

1 

0 

0 

0 

1 

6 

Somewhat 

suitable 

2 

0 

0 

2 

4 

27 

Somewhat 

unsuitable 

0 

0 

0 

0 

0 

0 

Very  unsuitable  0  0  0  0  0  0 


TABLE  38 

Additional  Data  Manipulation  Capabilities  Required 
(Number  who  mentioned  capability;  multiple  answers  allowed) 

NHRC  Higher  Medical  %  of 

NOHIMS  Level  Care  industrial  Total  Who 

Developers  Managers  Providers  Hygienists  TOTAL  Answered 


Statistical 

interface  1  2  0  1  4  27 

More  analytical 
capabilities  3 

More  output  of 
linked  data 
to  tape  1 


0  0  0  3  20 

0  0  0  1  7 


NOHIMS  specifically  mentioned  the  need  for  statistics  in  some  form.  Three  of 
the  NHRC  NOHIMS  developers  (20%  of  total  respondents)  suggested  that  NOHIMS 
should  be  enhanced  with  additional  analytical  capabilites.  One  developer 
suggested  creating  more  abilities  to  output  medical  and  exposure  data  to  tape 
for  analysis  in  other  statistical/analytical  software  packages.  As  mentioned 
above,  NOHIMS  extracts  laboratory  test  and  physical  examination  findings  values, 
reorganizes  the  data  into  a  fixed  length  record  format,  and  outputs  the  data  to 
tape  so  that  it  can  be  used  in  standard  statistical  software  packages.  The 
records  can  be  produced  for  subsets  of  patients  defined  by  either  the  industrial 
or  medical  components  or  by  combining  lists  from  both  components.  It  can  also 
extract  data  for  subsets  of  laboratory  tests  and  physical  examination  results. 

It  does  not  extract  other  types  of  medical  data  such  as  diagnoses,  and  does  not 
extract  data  from  the  industrial  component.  The  NHRC  developer  was  suggesting 
that  more  capabilities  such  as  this  one  should  be  developed. 

Overall  Assessment 

Table  39  shows  the  respondents’  overall  assessment  of  the  adequacy  of 
NOHIMS  for  Navy  information  processing  needs.  Ninety-five  percent  of  those  who 
responded  to  the  question  gave  NOHIMS  a  rating  of  adequate  or  better. 
Approximately  two-thirds  of  these  people  (or  63%  of  the  total  who  responded) 
gave  NOHIMS  a  rating  of  very  adequate  for  Navy  information  processing  needs. 

The  NHRC  NOHIMS  developers  gave  NOHIMS  a  lower  rating  than  the  other  groups  of 
respondents.  Three  of  the  four  developers  evaluated  NOHIMS  as  adequate  rather 
than  very  adequate.  This  may  be  a  reflection  of  their  strong  desire  for 
expanded  data  manipulation  capabilities.  Although  we  skipped  over  most  of  the 
previous  questions  with  the  medical  care  providers  because  of  lack  of  time,  we 
did  ask  the  medical  care  providers  to  assess  the  overall  adequacy  of  NOHIMS  for 
Navy  information  processing  needs.  Half  of  the  providers  felt  that  they  could 
not  evaluate  this  aspect  of  NOHIMS;  the  other  half  gave  NOHIMS  a  rating  of 
adequate  or  better  for  meeting  Navy  information  processing  needs. 


Summarv 


All  of  the  interviewees  who  assessed  the  suitability  of  NOHIMS  for  Navy 
information  collection  needs  thought  that  NOHIMS  was  very  suitable. 
Nevertheless,  there  were  several  additional  categories  of  data  that  they  felt 
NOHIMS  should  collect.  The  six  that  were  mentioned  most  frequently  were  data 
relating  to  accidents  and  incidents  (43%),  occupational  history  data  (39%), 
illness  and  injury  data  (39%),  medical  history  data  (30%),  sick  leave  or 
absenteeism  data  (26%),  and  mortality  data  (22%).  NOHIMS  already  has  the 
design  potential  to  collect  the  first  four  types  of  data,  but  the  features  have 
not  yet  been  implemented.  Modifications  to  NOHIMS  design  would  be  required  to 
collect  sick  leave  or  absenteeism  data  and/or  mortality  data. 


Seventy-two  percent  of  those  who  evaluated  NOHIMS  with  regard  to 
suitability  for  Navy  data  retrieval  needs  rated  NOHIMS  as  very  suitable.  Many 
changes  were  suggested  by  the  interviewees  in  order  to  make  NOHIMS  more 
suitable.  The  most  frequently  mentioned  need  was  the  ability  to  retrieve 
historical  exposure  data,  which  was  mentioned  by  three  of  the  18  respondents 
(17%). 


TABLE  39 

Overall  Assessment  of  Adequacy  of  NOHIMS 
for  Navy  Information  Processing  Needs 
(Number  who  mentioned  rating) 

NHRC  Higher  Medical  %  of 

NOHIMS  Level  Care  Industrial  Total  Who 

Developers  Managers  Providers  Hygienists  TOTAL  Answered 


Very  adequate  1 
Adequate  3 
Somewhat  adequate  0 
Somewhat  inadequate  0 
Inadequate  0 
Very  inadequate  0 


TOTAL  WHO  ANSWERED 


No  Comment 


TOTAL  INTERVIEWED 


Sixty-seven  percent  of  the  respondents  rated  NOHIMS  as  very  suitable  for 
Navy  information  manipulation  needs.  The  main  criticisms  of  NOHIMS'  data 
manipulation  capabilities  were  that  NOHIMS  needs  more  analytical  capabilities 
and  a  statistical  interface.  Six  out  of  15  respondents  (40%)  mentioned  the  need 
for  either  statistical  or  analytical  capabilities  (one  NHRC  NOHIMS  developer 
mentioned  both  statistics  and  analytical  capabilities).  These  capabilities  were 
of  special  concern  to  the  NHRC  NOHIMS  developers  who  intend  to  use  the  database 
for  research  purposes. 

Overall,  95  percent  of  the  interviewees  thought  that  NOHIMS  was  adequate  or 
very  adequate  for  Navy  information  processing  needs. 


ASSESSMENT  OF  OVERALL  SYSTEM  PERFORMANCE 

The  overall  system  performance  of  NOHIMS  has  been  evaluated  in  two  ways. 
The  first  subsection  below  describes  the  users'  assessment  of  NOHIMS  in  twelve 
areas  of  performance.  The  second  subsection  contains  the  results  of  a 
structured  attitude  appraisal  of  the  same  users  to  determine  their  opinions  of 
the  usefulness  and  importance  of  NOHIMS  in  their  jobs. 


Evaluation  of  NOHIMS  Performance 


In  order  to  assess  the  performance  of  NOHIMS  from  the  system  user's 
perspective,  we  generated  a  set  of  twelve  ratings  to  gain  an  insight  into  how 
well  NOHIMS  users  felt  the  system  was  performing.  Since  length  of  experience 
with  using  NOHIMS  most  likely  would  affect  these  ratings,  we  also  asked  how  many 
months  an  individual  had  used  or  been  exposed  to  NOHIMS.  Fourteen  users 
consisting  of  five  medical  care  providers,  five  industrial  hygienists,  two  data 
entry  personnel,  and  two  system  managers  made  these  ratings.  A  sixth  medical 
care  provider  felt  he  could  not  rate  NOHIMS  performance  because  he  had  had  so 
little  exposure  to  the  system.  The  users  sometimes  felt  that  they  could  not 
comment  on  a  particular  aspect  of  NOHIMS  performance  because  of  lack  of 
familiarity  with  that  area  of  performance.  Thus,  the  number  of  users  who 
responded  varies  from  question  to  question. 

The  first  four  ratings  addressed  problems  that  NOHIMS  may  have  given  in  the 
areas  of  reliability,  downtime,  communication  lines,  and  the  man-machine 
interface.  Table  40  presents  the  users'  assessment  of  NOHIMS  reliability.  Of 
those  individuals  interviewed  who  felt  they  could  make  this  rating,  44  percent 
had  encountered  no  problems  and  56  percent  reported  some  problems.  Of  the 
NOHIMS  users  who  experienced  some  problems  with  system  reliability,  all  reported 
that  these  troubles  stemmed  from  early  problems  with  terminal  equipment  and 
software  bugs  that  subsequently  were  fixed  when  they  were  discovered.  They 
considered  NOHIMS  software  to  be  reliable  at  the  Lime  of  the  interviews  in 
September  and  November  of  1985.  As  one  medical  ancillary  put  it,  "I  have  never 
even  seen  an  error  message."  One  system  manager  reported  that  "software  errors 
are  very  rare  now;  basically,  the  software  is  clean." 


Table  41  shows  how  system  users  were  affected  by  NOHIMS  downtime. 
Seventeen  percent  of  the  individuals  who  made  this  rating  reported  no  problems 
with  system  downtime,  75  percent  experienced  some  problems,  and  another  eight 


TABLE  40 

Rating  of  Problems  NOHIMS  Has  Given  in  the  Area  of  Reliability 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

Data  Entry 
Clerks 

System 

Managers 

TOTAL 

%  of 

Total  Who 
Answered 

No  problems 

1 

1 

2 

0 

4 

44 

Some  problems 

1 

3 

0 

1 

5 

56 

Many  problems 

0 

0 

0 

0 

0 

0 

TOTAL 

WHO  ANSWERED 

2 

4 

2 

1 

9 

No  Comment 

4 

1 

0 

1 

6 

TOTAL 

INTERVIEWED 

6 

5 

2 

2 

15 

TOTAL 

INTERVIEWED 


TABLE  41 

Rating  of  Problems  NOHIMS  Has  Given  in  the  Area  of  Downtime 
(Number  who  mentioned  rating) 

Medical  %  of 

Care  Industrial  Data  Entry  System  Total  Who 

Providers  Hygienists  Clerks  Managers  TOTAL  Answered 


No  problems 

1 

0 

1 

0 

2 

17 

Some  problems 

2 

4 

1 

2 

9 

75 

Many  problems 

1 

0 

0 

0 

1 

8 

percent  encountered  many  problems.  The  individual  who  reported  many  problems 
with  system  downtime  was  a  medical  care  provider  in  San  Diego  who  found  the 
occasional  inaccessibility  of  NOHIMS  when  the  system  was  down  to  be  "a  pain  in 
the  neck." 

The  troubles  that  NOHIMS  users  who  experienced  some  problems  with  system 
downtime  had  early  on  were  related  to  hardware.  These  problems  subsequently 
were  resolved.  The  system  is  stable  now  in  Bremerton.  The  system  in  San  Diego 
experienced  some  additional  downtime  during  the  last  half  of  1985  when  NHRC  pre¬ 
empted  the  operational  hardware  to  conduct  NOHIMS  bench  marking  in  preparation 
for  Navy-wide  NOHIMS  hardware  acquisition. 

Of  the  ten  individuals  interviewed  who  felt  that  they  could  rate  problems 
with  NOHIMS'  communication  lines  (see  Table  42),  20  percent  had  experienced  no 
problems  and  80  percent  reported  some  problems.  No  one  had  encountered  many 
problems  with  communication  lines,  and  those  that  did  occur  were  generally 
during  NOHIMS  implementation.  In  San  Diego,  the  industrial  hygienists  reported 
temporary  problems  with  communication  lines  and  occasional  disconnects.  The 
data  entry  clerk  and  medical  care  providers  in  San  Diego  mentioned  being  down  a 
few  times  because  of  modem  problems.  The  nature  of  the  problem  with 
communication  lines  in  Bremerton  was  that  they  experienced  difficulty  in 
obtaining  a  new  telephone  line  for  use  with  NOHIMS.  This  problem  was  resolved 
by  borrowing  one  line  from  an  industrial  hygienist. 

Nine  of  the  15  individuals  interviewed  refrained  from  rating  problems  in 
the  area  of  NOHIMS'  man-machine  interface  (see  Table  43).  Of  the  six  persons 
who  felt  that  they  could  make  this  rating,  half  reported  no  problems  and  half 
reported  some  problems.  No  one  had  experienced  many  problems  with  the  man- 
machine  interface.  The  data  entry  clerk  in  San  Diego  complained  of  being  locked 
out  of  the  system  from  time  to  time  when  system  resources  were  stretched  to 
capacity.  The  lock  table  problem  is  a  function  of  the  MUMPS  operating  system 
currently  in  use  on  the  PDP  11/24  at  NHRC  and  will  be  resolved  when  the 
operating  system  is  upgraded. 

The  individuals  interviewed  were  invited  to  comment  on  any  other 
performance  problems  with  NOHIMS  that  they  had  encountered  (Other  category). 

One  medical  care  provider  was  concerned  in  certain  cases  when  the  exposure 
measurement  for  a  worker  did  not  correspond  to  the  medical  tests  recommended  by 
NOHIMS.  One  example  she  pointed  out  was  the  scheduling  of  medical  monitoring 
examinations  for  asbestos  exposure  when  the  worker's  measured  exposure  did  not 
exceed  the  Threshold  Limit  Value  (TLV).  This  apparent  discrepancy  can  be 
explained  by  Navy  policy,  namely,  all  workers  exposed  to  asbestos  are  monitored 
medically  regardless  of  the  level  of  their  exposure.  This  same  medical  care 
provider  had  also  seen  noise  measurements  over  the  TLV  without  a  noise 
examination  being  triggered  by  NOHIMS.  Follow-up  in  April  1986  found  that  most 
of  these  kinds  of  problems  had  been  resolved.  The  medical  care  provider 
interviewed  reported  that  the  problems  that  remain  are  a  result  of  inaccurate 
personnel  data  and  out-of-date  survey  data. 

Table  44  presents  the  magnitude  and  trend  of  noticeable  system  failures  as 
rated  by  NOHIMS  users.  Nine  individuals  commented  on  how  often  a  system  failure 
that  is  noticeable  to  the  user  occurs.  All  of  these  noticeable  failures  were 
attributed  to  hardware  downtime,  power  failures,  and  problems  with  the 
communication  lines/modem.  The  system  manager  in  San  Diego  said  that  failures 


TABLE  42 

Rating  of  Problems  NOHIMS  Has  Given  in  the  Area  of  Communication  Lines 

(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

Data  Entry 
Clerks 

System 

Managers 

TOTAL 

%  of 

Total  Who 
Answered 

No  problems 

1 

0 

1 

0 

2 

20 

Some  problems 

2 

3 

1 

2 

8 

80 

Many  problems 

0 

0 

0 

0 

0 

0 

<  a  > w 


TABLE  43 

Rating  of  Problems  NOHIMS  Has  Given  in  the  Area  of  Man-Machine  Interface 

(Number  who  mentioned  rating) 


Medical 


%  of 


Care 

Providers 

Industrial 

Hygienists 

Data  Entry 
Clerks 

System 

Managers 

TOTAL 

Total  Who 
Answered 

No  problems 

1 

0 

1 

1 

3 

50 

Some  problems 

1 

1 

1 

0 

3 

50 

Many  problems 

0 

0 

0 

0 

0 

0 

TABLE  44 

Rating  of  Magnitude  and  Trend  of  Noticeable  System  Failures 
(Number  who  mentioned  rating) 

Medical  ^ 

Care  Industrial  Data  Entry  System  Total  Who 

Providers  Hygienists _ Clerks  Managers  TOTAL  Answered 


A  noticeable 
(to  the  user) 
failure  happens: 


Never/None 

1 

0 

2 

0 

3 

34 

Once 

0 

1 

0 

0 

1 

11 

Very  seldom 

0 

0 

0 

1 

1 

11 

Once/week 

0 

1 

0 

1 

2 

22 

Once/ day 

0 

1 

0 

0 

1 

11 

Often  in 
the  past 

1 

0 

0 

0 

1 

11 

TOTAL  WHO 

ANSWERED 

2 

3 

2 

2 

9 

100 

No  Comment 

4 

2 

0 

0 

6 

TOTAL 

INTERVIEWED 

6 

5 

2 

2 

15 

And  that 
number  has 
been: 

Improving 

1 

3 

0 

2 

6 

100 

Steady 

0 

0 

0 

0 

0 

0 

Getting  worse 

0 

0 

0 

0 

0 

0 

! 


of  the  NOHIMS  software  (program  errors)  were  rare.  Six  NOHIMS  users  commented 
on  whether  the  number  of  system  failures  has  been  improving,  remaining  steady, 
or  getting  worse.  All  six  agreed  that  NOHIMS'  failure  record  has  been 
improving.  The  two  data  entry  clerks  did  not  comment  on  the  trend  of  system 
failures  since  they  had  never  noticed  a  failure  and  had  no  basis  for  judging  a 
change. 

In  Table  45  we  see  that  nine  of  the  eleven  NOHIMS  users  who  made  a  rating 
on  the  acceptability  of  the  number  of  NOHIMS  failures  or  errors  felt  that  the 
current  number  of  failures  or  errors  encountered  in  the  system  is  acceptable. 

One  industrial  hygienist  thought  the  current  failure/error  rate  was  somewhat 
unacceptable.  One  medical  ancillary  said  that  the  amount  of  downtime  was 
unacceptable. 

Table  46  shows  how  heavy  system  usage  affects  NOHIMS’  response  time  and 
delays  data  entry  as  rated  by  NOHIMS  users.  The  upper  half  of  Table  46  contains 
the  ratings  of  heavy  NOHIMS  usage  on  system  response  time.  Eight  of  the  eleven 
respondents  who  rated  the  effect  of  heavy  NOHIMS  usage  on  system  response  time 
concurred  that  there  would  be  a  system  slowdown  but  of  varying  degrees,  most 
likely  a  direct  reflection  of  how  much  they  use  NOHIMS.  All  three  of  the 
individuals  who  detected  no  effect  on  NOHIMS  response  time  with  heavy  system 
usage  were  at  Bremerton — two  industrial  hygienists  and  the  data  entry  clerk. 

Only  the  industrial  component  of  NOHIMS  is  running  at  Bremerton  in  an 
environment  where  no  other  users  are  competing  for  the  use  of  system  resources. 
The  system  manager  at  Bremerton,  however,  experiences  an  annoying  system 
slowdown  when  there  is  heavy  NOHIMS  usage.  He  is  hoping  that  when  production 
hardware  is  installed  at  his  site,  rather  than  the  prototype  test  hardware 
currently  in  use,  system  response  will  improve  even  with  heavy  NOHIMS  usage.  In 
contrast,  the  system  manager  and  one  industrial  hygienist  in  San  Diego  find  that 
there  is  a  terrible  slowdown  with  heavy  NOHIMS  usage.  It  is  made  even  worse 
when  other  MUMPS  users  not  interacting  with  NOHIMS  are  competing  for  the  PDP 
11/24's  limited  resources. 

In  the  lower  half  of  Table  46,  eight  individuals  rated  how  data  entry  is 
affected  by  heavy  NOHIMS  usage.  None  of  the  six  medical  care  providers  made 
this  rating  because  they  are  not  involved  in  the  entry  of  NOHIMS  data.  One 
industrial  hygienist  in  San  Diego  with  no  experience  in  entering  survey  data 
also  abstained  from  making  this  rating.  The  two  industrial  hygienists  who  said 
that  data  entry  is  never  delayed  by  system  response  time  were  at  Bremerton,  as 
was  the  data  entry  clerk  who  chose  the  never  delayed  rating.  The  Bremerton 
system  manager  reported  that  data  entry  at  his  NOHIMS  site  is  rarely  delayed  by 
system  response  time.  The  two  San  Diego  industrial  hygienists  felt  that  entry 
of  survey  data  is  rarely  delayed  by  system  response  time.  The  data  entry  clerk 
for  medical  data  in  San  Diego  responded  that  data  entry  is  occasionally  delayed 
by  system  response  time,  while  the  San  Diego  system  manager,  who  may  have  a 
larger  picture  of  all  aspects  of  NOHIMS  data  entry  operations,  indicated  that 
data  entry  is  often  delayed  by  system  response  time. 

In  Table  47,  NOHIMS  users  were  asked  to  rate  the  time  required  to  obtain  a 
display  of  NOHIMS  data  from  fast  to  slow.  Thirteen  of  the  15  individuals 
interviewed  made  this  rating,  of  which  92  percent  felt  that  NOHIMS  displays 
either  came  up  fast  (38%)  or  somewhat  fast  (54%).  No  one  thought  all  NOHIMS 
displays  were  slow  or  somewhat  slow.  One  medical  ancillary  observed  that  the 
time  varies  and  ranges  from  slow  to  fast.  The  industrial  hygienists  generally 
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TABLE  45 

Rating  of  Acceptability  of  the  Number  of  NOHIMS  Failures  or  Errors 

(Number  who  mentioned  rating) 

Medical  %  °f 

Care  Industrial  Data  Entry  System  Total  Who 

Providers  Hygienists  Clerks  Managers  TOTAL  Answered 


Acceptable 

Somewhat 

acceptable 

Somewhat 

unacceptable 

Unacceptable 


TOTAL  WHO 
ANSWERED 

No  Comment 

TOTAL 

INTERVIEWED 
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TABLE  46 

How  Heavy  System  Usage  Affects  NOHIMS  Response  Time  and  Delays  Data  Entry 

(Number  who  mentioned  rating) 

Medical  %  of 

Care  Industrial  Data  Entry  System  Total  Who 

Providers  Hygienists  Clerks _  Managers  TOTAL  Answered 


Heavy  NOHIMS 
usage  causes: 

A  terrible 
slowdown 

An  annoying 
slowdown 

A  noticeable 
slowdown 

No  effect 


TOTAL  WHO 
ANSWERED 

No  Comment 

TOTAL 

INTERVIEWED 


Data  entry  is: 
Never 
Rarely 

Occasionally 

Often 

delayed  by  system 
response  time 


TOTAL  WHO 
ANSWERED 

No  Comment 


TOTAL 

INTERVIEWED 


TOTAL  WHO 
ANSWERED 

No  Comment 


TOTAL 

INTERVIEWED 


HO 


rated  NOHIMS  as  having  a  faster  response  time,  suggesting  that  the  industrial 
component  responds  faster  than  the  medical  component. 

Six  medical  care  providers  and  the  San  Diego  system  manager  were  asked  to 
evaluate  the  effect  of  a  NOHIMS  failure  on  the  day-to-day  provision  of  medical 
care,  that  is,  when  the  system  is  down  for  any  reason  (see  Table  48).  Since  the 
NOHIMS  medical  component  is  not  operational  yet  at  Bremerton,  the  system  manager 
at  that  test  site  was  not  asked  to  make  this  rating.  The  effect  that  was 
mentioned  by  the  most  people  (83%)  was  that  medical  charts  are  held  up  in  data 
entry.  Half  of  those  individuals  responding  mentioned  that  NOHIMS  failures 
affect  medical  care  because  on-line  look-ups  cannot  be  done.  One-third  of  those 
responding  indicated  that  reports  usually  used  in  care  are  not  available  and 
that  work  procedures  must  be  changed  when  NOHIMS  is  down.  One  medical 
professional  commented  that  a  more  extensive  examination  may  have  to  be  done  if 
needed  information  in  NOHIMS  is  not  accessible,  which  would  increase  the  time 
that  the  care  provider  sees  the  patient.  One  care  provider  who  is  concerned 
with  the  timely  input  of  industrial  survey  data  mentioned  that  survey  data  would 
also  be  held  up  in  entry.  Only  one  care  provider  felt  that  when  NOHIMS  was 
down,  it  would  have  no  effect  on  the  provision  of  medical  care.  One  physician 
newly  exposed  to  NOHIMS  felt  unqualified  to  comment  because  of  his  lack  of 
experience  with  the  system. 

Eleven  NOHIMS  users  evaluated  the  effect  of  a  NOHIMS  failure  on  the 
administration  of  the  Occupational  Health  Unit  (see  Table  49).  The  most 
frequent  effect  cited  was  that  on-line  look-ups  cannot  be  done,  mentioned  by 
over  half  of  the  respondents.  Next  in  frequency  of  mention  were  that  survey 
data  are  held  up  in  entry  (36%)  and  that  data  entry  gets  backlogged  (36%).  Of 
those  individuals  responding,  27  percent  mentioned  that  medical  charts  would  be 
held  up  in  data  entry.  Another  27  percent  thought  that  when  NOHIMS  was  down,  it 
would  have  no  effect  on  the  administration  of  the  Occupational  Health  Unit.  Two 
of  these  three  respondents  were  at  Bremerton.  A  few  NOHIMS  users  thought  work 
procedures  must  be  changed  (to  do  other  useful  work  while  the  system  is  down) 
and  that  reports  usually  used  in  care  would  not  be  available. 

In  Table  50,  NOHIMS  users  were  asked  to  rate  the  number  of  major  "bugs"  in 
the  NOHIMS  software  that  affect  system  performance.  Almost  three-quarters  of 
the  interviewees  who  made  this  rating  felt  that  NOHIMS  software  has  no  major 
bugs  (73%).  These  eight  respondents  included  the  data  entry  personnel  and 
system  managers  at  both  San  Diego  and  Bremerton,  individuals  that  log  more  time 
on  the  system  than  any  other  NOHIMS  users.  One  medical  care  provider  and  one 
industrial  hygienist  reported  noticing  one  or  two  major  bugs.  The  medical  care 
provider,  an  ancillary,  did  not  mention  what  the  bugs  were.  The  industrial, 
hygienist  qualified  his  response  by  stating  that  most  bugs  have  been  worked  out 
now.  The  lone  industrial  hygienist  who  reported  several  major  bugs  identified 
them  as  "incorrectly  assigned  environments,  incorrectly  assigned  lab  tests,  and 
personnel  assigned  to  environments  incorrectly,"  which  are  really  database 
errors,  not  software  bugs.  This  individual  had  been  exposed  to  NOHIMS  for  only 
one  month  and  probably  was  noticing  that  the  personnel  data  in  NOHIMS  are 
inaccurate  because  the  Personnel  Extract  File  (PEF)  passed  over  to  NOHIMS 
monthly  is  not  up-to-date.  None  of  the  individuals  making  this  rating  felt  that 
there  were  many  major  bugs  in  the  NOHIMS  software,  probably  reflecting  the 
maturity  of  NOHIMS  which  has  been  running  in  a  production  mode  in  both  San  Diego 
and  Bremerton  for  a  considerable  length  of  time. 
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TOTAL  WHO 
ANSWERED 

No  Comment 


TOTAL 

INTERVIEWED 


TABLE  49 

Effect  of  a  NOHIMS  Failure  on  the  Administration  of  the 
Occupational  Health  Unit 

(Number  who  mentioned  effect;  multiple  answers  allowed) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

Data  Entry 
Clerks 

System 

Managers 

TOTAL 

%  of 

Total  Who 
Answered 

On-line  look-ups 
cannot  be  done 

2 

2 

0 

2 

6 

55 

Survey  data  are 
held  up  in  entry 

1 

2 

0 

1 

4 

36 

Data  entry  gets 
backlogged 

1 

0 

1 

2 

4 

36 

Medical  charts 
are  held  up  in 
data  entry 

2 

0 

0 

1 

3 

27 

No  effect  on 
administration 

0 

2 

1 

0 

3 

27 

Work  procedures 
must  be  changed 

0 

1 

1 

0 

2 

18 

Reports  usually 
used  in  care  are 
not  available 

0 

1 

0 

0 

1 

9 

TOTAL  WHO 

ANSWERED  2  5  2  2  11  100 

No  Comment  4  0  004 

TOTAL 

INTERVIEWED  6  5  2  2  15 


Analysis  of  NOHIMS  users'  responses  to  our  inquiry  about  how  many  months 
they  have  used  or  been  exposed  to  the  system  resulted  in  the  following  findings 
presented  here  by  class  of  NOHIMS  users.  Of  the  medical  care  providers,  the 
longest  involvement  was  36  months  by  the  Head  of  the  Occupational  Health  Unit  at 
North  Island,  San  Diego  who  wore  two  hats.  He  participated  heavily  initially  in 
the  design  of  the  medical  encounter  forms  and  then  later  on  as  a  medical  care 
provider  user.  The  next  most  significant  longevity  was  that  reported  by  one  of 
the  medical  ancillaries  who  had  interacted  with  the  medical  component  of  NOHIMS 
for  15  months.  The  second  medical  ancillary  and  one  of  the  physicians  had  each 
worked  with  NOHIMS  for  12  months.  One  physician's  assistant  had  two-and-one 
half  months'  experience  with  NOHIMS  at  the  time  of  our  interviews  in  September 
of  1985  and  one  physician  was  so  newly  arrived  at  the  North  Island  Occupational 
Health  Unit  that  he  had  had  virtually  no  exposure  to  NOHIMS.  The  average  length 
of  exposure  to  NOHIMS  for  medical  care  providers  as  of  September  1985  was  15.5 
months. 

One  of  the  industrial  hygienists  at  the  Industrial  Hygiene  Division  (IHD) 
in  San  Diego  also  wore  two  hats  in  the  development  of  NOHIMS.  This  individual 
spent  48  months  in  her  role  as  a  system  developer  and  then  later  on  30  months  as 
an  industrial  hygienist  user.  One  of  her  IHD  colleagues  had  been  exposed  to 
NOHIMS  for  10  to  11  months.  The  industrial  hygienist  at  the  San  Diego  Naval  Air 
Rework  Facility  (NARF)  had  one  month  of  exposure  to  NOHIMS  at  the  Lime  of  our 
interviews.  The  two  industrial  hygienists  in  Bremerton  each  reported 
approximately  11  months'  use  of  the  industrial  component  of  NOHIMS  at  that  test 
site.  The  average  length  of  exposure  to  NOHIMS  for  industrial  hygienists  as  of 
September  1985  was  16.3  months,  slightly  longer  than  that  for  medical  care 
providers  since  the  industrial  component  of  NOHIMS  was  developed  before  the 
medical  component  was  implemented. 

At  the  time  of  our  interviews  in  San  Diego  during  September  of  1985,  the 
data  entry  clerk  at  the  North  Island  Occupational  Health  Unit  had  been  on  the 
job  just  two  months.  He  was  preceded  by  two  other  data  entry  clerks  whom  we 
were  unable  to  interview.  The  first  and  only  data  entry  clerk  at  Bremerton  had 
been  on  the  job  six  months  as  of  September  1985.  The  average  length  of  exposure 
to  NOHIMS  for  the  data  entry  personnel  we  interviewed  was  4  months. 

Of  the  two  NOHIMS  system  managers,  the  one  in  San  Diego  had  been  involved 
with  the  system  for  36  months  at  the  time  of  our  interviews.  The  Bremerton 
system  manager  had  held  this  position  for  18  months  as  of  September  1985, 
yielding  an  average  of  27  months  of  exposure  to  NOHIMS  for  the  two  system 
managers.  Thus,  in  terms  of  length  of  exposure  to  NOHIMS,  the  system  managers 
on  the  average  had  the  greatest  amount  of  exposure  to  NOHIMS,  while  the  data 
entry  clerks  had  the  least  amount  of  exposure. 


Summarv 


In  the  area  of  possible  problems  with  NOHIMS  performance,  the  following 
findings  emerged  from  our  interviews  with  the  15  NOHIMS  users.  NOHIMS  software 
was  considered  reliable  at  the  time  o£  our  interviews.  Early  system  downtime 
was  related  to  hardware.  The  system  is  stable  now  in  Bremerton.  There  is 
occasional  system  downtime  in  San  Diego  caused  by  hardware  problems.  There  were 
some  problems  with  communication  lines  in  the  beginning  but  the  situation  is 
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fairly  stable  now.  The  most  significant  problem  mentioned  in  the  NOHIMS  man- 
machine  interface  was  the  lock  table  problem  that  causes  users  to  be  locked  out 
of  NOHIMS  when  the  PDP  11/24  system  resources  are  stretched  to  capacity.  This 
problem  will  be  resolved  when  the  operating  system  is  upgraded.  The  problem 
mentioned  by  one  medical  care  provider  of  seeing  noise  measurements  over  the 
Threshold  Limit  Value  without  a  noise  examination  being  triggered  by  NOHIMS  was 
investigated.  Problems  that  still  exist  are  a  result  of  out-of-date  survey  data 
and  inaccurate  personnel  data,  not  performance  problems. 

All  noticeable  system  failures  were  attributed  to  hardware  downtime,  power 
failures,  and  problems  with  communication  lines  and  the  modem.  Failures  of  the 
NOHIMS  software  (program  errors)  were  rare.  All  respondents  agreed  that  NOHIMS' 
failure  record  has  been  improving  and  60  percent  felt  that  the  current  number  of 
failures  or  errors  is  acceptable. 

Eight  of  eleven  individuals  rating  the  effect  of  heavy  NOHIMS  usage  on 
system  response  time  concurred  that  there  would  be  a  system  slowdown  but  of 
varying  degrees.  The  three  individuals  who  detected  no  effect  on  NOHIMS 
response  time  with  heavy  system  usage  were  at  Bremerton.  Most  respondents 
agreed  that  data  entry  would  be  delayed  in  varying  amounts  by  slow  system 
response  time  except  for  three  NOHIMS  users  at  Bremerton  who  reported  that  data 
entry  is  never  delayed  by  system  response  time  at  that  test  site. 

Of  13  NOHIMS  users,  92  percent  felt  that  NOHIMS  displays  either  came  up 
fast  or  somewhat  fast.  The  medical  component  was  rated  somewhat  slower  than  the 
industrial  component. 

The  effects  of  a  NOHIMS  failure  on  the  day-to-day  provision  of  medical  care 
mentioned  most  frequently  by  respondents  were  that  medical  charts  are  held  up  in 
data  entry  (83%),  that  on-line  look-ups  cannot  be  done  (50%),  that  reports 
usually  used  in  care  are  not  available  (33%),  and  that  work  procedures  must  be 
changed  when  NOHIMS  is  down  (33%).  The  effects  on  the  administration  of  the 
Occupational  Health  Unit  when  a  NOHIMS  failure  occurs  mentioned  most  frequently 
by  respondents  were  that  on-line  look-ups  cannot  be  done  (55%),  that  survey  data 
are  held  up  in  entry  (36%),  and  that  data  entry  gets  backlogged  (36%). 

Almost  three-quarters  of  the  respondents  felt  that  NOHIMS  software  has  no 
major  bugs. 

As  of  September  1985,  the  average  length  of  exposure  to  NOHIMS  was  15.5 
months  for  medical  care  providers,  16.3  months  for  industrial  hygienists,  27 
months  for  the  two  NOHIMS  system  managers,  and  4  months  for  data  entry  clerks. 

In  summary,  NOHIMS  has  been  running  in  a  production  mode  in  both  San  Diego 
and  Bremerton  for  a  considerable  length  of  time.  The  system  is  stable  at  both 
test  sites  and  the  majority  of  NOHIMS  users  are  satisfied  with  system  software 
and  hardware  performance,  with  hardware  downtime  being  a  much  more  likely  system 
failure  than  software  program  errors.  System  response  time  can  be  expected  to 
improve  when  NOHIMS  is  migrated  onto  operational  hardware  from  its  present 
installation  on  R&D  hardware  and  is  running  under  an  upgraded  MUMPS  operating 
system. 
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Structured  Appraisal  of  the  Performance  of  NOHIMS 

In  addition  to  analyzing  the  responses  of  NOHIMS  users  to  the  set  of  twelve 
ratings  assessing  NOHIMS  performance  presented  in  the  previous  subsection, 
interviewees  were  asked  to  respond  to  22  statements  reflecting  possible 
attitudes  or  opinions  that  users  of  NOHIMS  might  hold.  In  this  structured 
appraisal  of  the  performance  of  NOHIMS,  respondents  were  instructed  to  rate  each 
of  the  22  statements  on  a  5-point  scale  consisting  of  the  following  consecutive 
points:  Strongly  Agree,  Agree,  Neutral  Opinion,  Disagree,  and  Strongly 
Disagree.  The  rating  form  that  was  used  may  be  found  in  Component  21  of 
Appendix  A. 

Of  the  15  NOHIMS  users  interviewed,  14  individuals  responded  to  this 
structured  appraisal  by  placing  an  "X"  at  the  point  on  the  scale  indicating 
their  extent  of  agreement  or  disagreement  with  each  statement.  Those  responding 
to  this  short  exercise  consisted  of  five  medical  care  providers,  five  industrial 
hygienists,  two  data  entry  personnel,  and  two  system  managers.  A  sixth  medical 
care  provider  abstained  from  responding  because  he  had  had  so  little  exposure  to 
NOHIMS.  We  ended  up  with  one  extra  set  of  ratings  from  an  individual  we  were 
unable  to  identify.  Since  ratings  from  all  of  those  interviewed  were  accounted 
for  and  because  we  did  not  know  if  the  mystery  return  came  from  a  legitimate 
NOHIMS  user,  we  decided  to  omit  this  individual's  ratings  from  the  analysis. 
However ,  it  should  be  noted  that  these  ratings  were  more  negative  than  those  we 
analyzed.  One  medical  care  provider  and  one  of  the  data  entry  clerks  did  not 
return  their  ratings  to  us  until  early  April  1986  whereas  all  of  the  other 
NOHIMS  users  made  their  ratings  in  September  1985.  It  is  not  known  if  this 
delay  in  responding  affected  their  ratings  in  any  way. 

Histograms  depicting  the  ratings  made  by  the  14  respondents  for  each  of  the 
22  statements  are  shown  in  Figure  1  along  with  the  overall  average  rating.  The 
location  of  where  on  the  5-point  scale  the  "X"  was  placed  by  each  respondent  is 
represented  by  a  letter  D,  I,  M,  or  S  denoting  the  class  of  NOHIMS  users  to 
which  each  respondent  belonged  (D=Data  Entry  Personnel,  I=Industrial  Hygienists, 
M=Medical  Care  Providers,  and  S=System  Managers).  All  14  individuals 
participating  in  this  exarcise  rated  Statements  1,  2,  3,  4,  6,  7,  8,  9,  10,  11, 
12,  15,  17,  18,  20,  21,  and  22;  13  respondents  rated  Statements  5,  13,  16,  and 
19;  and  eleven  people  rated  Statement  14. 

In  the  analysis  of  the  ratings,  the  response  scale  was  assigned  weights 
from  +2  to  -2  in  the  following  mannner: 


Strongly  Agree  +2 
Agree  +1 
Neutral  Opinion  0 
Disagree  -1 
Strongly  Disagree  -2 


If  a  NOHIMS  user  selected  "Strongly  Agree"  as  his  or  her  response  to  all  22 
statements,  this  individual's  summated  score  on  the  attitude  scale  would  be  +44. 
Conversely,  if  this  individual  selected  "Strongly  Disagree"  as  his  or  her 
response  to  all  22  statements,  the  summated  score  would  be  -44.  Thus,  the  range 
of  possible  scores  for  an  individual  on  this  attitude  scale  is  -44  to  +44.  The 
weights  assigned  to  Statements  3,  6,  9,  11,  15,  and  20  were  reversed  since  these 


Figure  1.  Histograms  Depicting  Ratings  by  14  Respondents  to 
(Cont.)  22  Statements  about  the  Performance  of  NOHIMS. 
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9.  NOHIMS  has  some  major  problems  that  need 
correction. 
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Figure  1.  Histograms  Depicting  Ratings  by  14  Respondents  to 
(Cont.)  22  Statements  about  the  Performance  of  NOHIMS. 


10.  If  there  were  budget  cuts  at  this  activity,  I  would  rather 
see  other  services  that  I  need  cut  before  I  lost  NOHIMS. 

D 

D 

I 

I 

I  M 

S  M  I 

S  M  I  M 


®  =  Overall  Average 


®  =  Overall  Average 


Figure  1.  Histograms  Depicting  Ratings  by  14  Respondents  to 
(Cont.)  22  Statements  about  the  Performance  of  NOHIMS. 


16.  Worker/patient  satisfaction  seems  to  be  running 
higher  since  NOHIMS  was  introduced. 
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17.  I  can  see  how  NOHIMS  can  be  a  boon  to  other  users. 
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18.  With  NOHIMS,  I  am  able  to  get  more  done  in  a  day. 
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Figure  1.  Histograms  Depicting  Ratings  by  14  Respondents  to 
(Cont.)  22  Statements  about  the  Performance  of  NOHIMS. 


19.  The  records  produced  by  NOHIMS  are  more  amenable 
to  review  and  better  meet  Navy  standards. 
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20.  The  confidentiality  of  the  worker's/patient's  record  is  more 
vulnerable  with  NOHIMS  than  it  was  with  the  manual  system. 
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21.  I  don't  care  much  what  NOHIMS  costs  to  operate, 
we  need  it  to  handle  our  workload  efficiently. 


D 

I 


I  M 

I  M 


+  2  +1  0  -1  -2 
Strongly  Agree  Neutral  Disagree  Strongly 

Agree  Opinion  Disagree 


LEGEND:  D  =  Data  Entry  Personnel,  I  =  Industrial  Hygienists, 
M  =  Medical  Care  Providers,  S  =  System  Managers. 


®  =  Overall  Average 


».  - 


in  jT»_. 


Figure  1.  Histograms  Depicting  Ratings  by  14  Respondents  to 
(Cont.)  22  Statements  about  the  Performance  of  NOHIMS. 


22.  If  NOHIMS  were  to  be  taken  out,  I  would  be  willing  to 
make  a  reasonable  effort  to  get  it  back  in  service. 
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statements  reflect  negative  rather  than  positive  attitudes  toward  NOHIMS.  A 
discussion  of  the  rating  results  for  each  statement  is  presented  below. 

For  Statement  1,  13  of  the  14  respondents  either  agreed  or  strongly  agreed 
that  worker/patient-related  information  is  more  accessible  and  available  more 
quickly  with  NOHIMS.  One  respondent  expressed  a  neutral  opinion.  The  overall 
average  rating  for  this  statement  was  +1.6,  approximately  halfway  between  Agree 
and  Strongly  Agree.  Industrial  hygienists  agreed  more  strongly  with  this 
statement  than  any  other  class  of  NOHIMS  users. 

Thirteen  of  the  14  individuals  responding  to  Statement  2  either  agreed  or 
strongly  agreed  that  "as  a  result  of  NOHIMS,  I  am  able  to  do  a  better  job."  One 
respondent  expressed  a  neutral  opinion.  The  overall  average  rating  for  this 
statement  was  +1.4.  The  two  system  managers  as  a  NOHIMS  user  class  agreed  the 
most  strongly  with  this  statement,  followed  by  medical  care  providers,  data 
entry  personnel,  and  lastly  industrial  hygienists. 

The  distribution  of  ratings  for  Statement  3,  "the  performance  of  NOHIMS 
falls  short  of  what  I  expected,"  is  more  dispersed,  probably  reflecting  more 
than  anything  else  a  wide  divergence  in  expectations  for  NOHIMS.  If  one's 
expectations  for  NOHIMS'  performance  were  unrealistically  high  initially,  then 
most  likely  the  system  will  fall  short  of  meeting  these  expectations, 
particularly  in  the  early  stages  of  system  development  and  implementation.  On 
the  other  hand,  if  one  is  skeptical  initially  about  the  expected  performance  of 
NOHIMS,  then  one  is  likely  to  be  pleasantly  surprised  as  the  system  takes  shape 
and  form.  It  is  notable  that  five  individuals  held  a  neutral  opinion.  The 
overall  average  rating  was  +0.6,  indicating  more  disagreement  with  this 
statement  than  agreement  since  this  was  a  negative  statement  about  NOHIMS.  As  a 
class,  the  system  managers  disagreed  the  most  strongly  that  NOHIMS  fell  short  of 
their  expectations. 

The  distribution  of  ratings  for  Statement  4,  "I  could  never  go  back  to 
using  the  old  manual  record  system  now  that  l  have  been  using  NOHIMS,"  is  also 
quite  dispersed.  The  overall  average  rating  was  +0.8  indicating  that  there  was 
substantially  more  agreement  with  this  statement  than  disagreement.  The  system 
managers  and  data  entry  personnel  expressed  more  agreement  with  the  statement 
than  the  other  two  classes  of  NOHIMS  users,  and  industrial  hygienists  agreed 
more  with  the  statement  than  medical  care  providers.  This  is  not  a  surprising 
finding  because  medical  care  providers  can  always  return  to  the  traditional 
manual  method  of  keeping  medical  records  that  they  learned  in  medical  school. 

The  majority  opinion  in  response  to  Statement  5  is  that  NOHIMS  catches  more 
human  errors  than  the  old  manual  system  did.  However,  of  the  13  individuals 
responding  to  this  statement,  four  held  a  neutral  opinion.  The  overall  average 
rating  was  +1.0,  exactly  at  the  Agree  point  on  the  histogram.  The  two  system 
managers  as  a  class  agreed  the  most  strongly  with  this  statement. 

All  14  respondents  to  Statement  6  disagreed  to  some  extent  that  NOHIMS 
should  not  have  been  implemented  at  their  activity.  The  overall  average  rating 
was  +1.7,  closer  to  Strongly  Disagree  than  to  Disagree.  Again,  the  two  system 
managers  as  a  class  held  the  strongest  opinion  on  this  statement.  The  rating 
results  for  this  statement  are  interesting  in  light  of  some  of  the  criticisms  of 
NOHIMS  revealed  in  the  analysis  of  other  statements  in  this  structured  attitude 
appraisal.  The  findings  here  suggest  that  frustration  with  and  negativism 
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toward  NOHIMS  may  relate  to  early  and  current  problems  of  system  implementation 
and  not  to  the  users'  long-range  view  of  the  potential  of  NOHIMS. 

The  distribution  of  ratings  for  Statement  7,  "I  rarely  have  to  wait  for 
necessary  worker/patient  information  because  the  NOHIMS  system  is  down,"  is  very 
dispersed  with  the  overall  average  rating  being  +0.6,  approximately  halfway 
between  Agree  and  Neutral  Opinion.  Those  respondents  who  disagreed  with  this 
statement  probably  were  expressing  their  frustration  with  any  system  downtime 
although  downtime  is  not  a  regular  occurrence  at  present,  particularly  at 
Bremerton . 

All  14  respondents  to  Statement  8  agreed  that,  in  general,  NOHIMS  is  better 
than  the  old  manual  system  of  record  keeping.  The  overall  average  rating  was 
+1.4,  about  halfway  between  Agree  and  Strongly  Agree. 

Six  of  the  14  respondents  to  Statement  9  expressed  a  neutral  opinion 
regarding  whether  or  not  NOHIMS  has  some  major  problems  that  need  correction, 
three  respondents  agreed,  and  five  respondents  either  disagreed  or  disagreed 
strongly.  The  overall  average  rating  was  +0.3,  slightly  in  the  direction  of 
Disagree  from  Neutral  Opinion.  One  gratuitous  comment  on  the  rating  form  for  an 
industrial  hygienist  who  agreed  that  NOHIMS  had  major  problems  that  need 
correction  indicated  that  these  were  problems  in  the  past  that  "seem  to  have 
been  worked  out . " 

Statement  10  poses  a  difficult  choice  for  the  NOHIMS  user,  and  the 
responses  to  this  statement  reflect  this  dilemma.  If  there  were  budget  cuts  at 
a  system  user's  activity,  what  other  needed  services  would  a  user  be  willing  to 
give  up  before  losing  NOHIMS?  Most  respondents  appear  to  have  dealt  with  this 
statement  in  terms  of  their  own  perception  of  what  the  alternate  valuable 
services  might  be  that  they  would  have  to  give  up  in  order  to  retain  NOHIMS. 

One  respondent  out  of  14  straddled  the  fence  by  expressing  a  neutral  opinion. 
Three  respondents  opted  in  favor  of  other  needed  services,  but  ten  respondents 
agreed  that  they  would  prefer  to  see  cuts  in  other  services  before  losing 
NOHIMS.  The  overall  average  rating  was  +0.6,  closer  to  Agree  than  to  Neutral 
Opinion.  The  two  system  managers  as  a  class  voted  the  most  strongly  for  NOHIMS. 
The  medical  care  providers  expressed  the  most  disagreement  with  Statement  10, 
although  three  of  the  five  medical  care  providers  expressed  agreement. 

Eleven  out  of  14  respondents  disagreed  or  strongly  disagreed  with  Statement 
11  that  "NOHIMS  has  'goofed'  up  worker/patient  records  more  times  than  I  care  to 
remember."  Two  respondents  held  a  neutral  opinion,  and  one  respondent  agreed 
with  this  statement.  This  latter  individual  was  an  industrial  hygienist, 
exposed  to  NOHIMS  for  only  one  month,  who  probably  was  reacting  to  the 
inaccuracies  in  the  Personnel  Extract  File  discussed  in  the  previous  subsection. 
Since  these  personnel  data  are  passed  over  to  NOHIMS  on  a  monthly  basis  from  the 
NARF  Personnel  Department  in  San  Diego,  NOHIMS  has  no  control  at  present  over 
either  their  accuracy  or  currency.  The  overall  average  rating  for  Statement  11 
was  +1.0,  squarely  at  Disagree  on  the  6-point  rating  scale. 

Of  the  14  NOHIMS  users  responding  to  Statement  12,  seven  individuals  either 
agreed  or  strongly  agreed  that  the  quality  of  care  has  been  improved  as  a  result 
of  NOHIMS.  The  other  seven  respondents  held  a  neutral  opinion.  Both  system 
managers,  four  industrial  hygienists,  and  one  data  entry  cLerk  chose  the  neutral 
opinion  rating.  All  five  medical  care  providers  agreed  or  strongly  agreed  that 
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the  quality  of  care  has  been  improved  as  a  result  of  N0H1MS.  Their  average 
rating  was  +1.6,  more  than  halfway  between  Agree  and  Strongly  Agree  compared  to 
an  overall  average  rating  of  +0.7,  influenced  by  50  percent  of  the  respondents 
expressing  a  neutral  opinion.  If  it  is  agreed  that  medical  care  providers  are 
in  the  best  position  to  judge  the  quality  of  care  since  the  advent  of  NOHIMS, 
then  they  have  expressed  a  strong  vote  of  confidence  in  the  system. 

Of  the  13  NOHIMS  users  who  responded  to  Statement  13,  ten  either  agreed  or 
strongly  agreed  that  from  an  administrative  point  of  view,  NOHIMS  provides 
timely  data  for  making  management  decisions  that  were  not  available  with  the 
previous  manual  system.  Three  respondents  expressed  a  neutral  opinion  regarding 
this  statement.  The  overall  average  rating  was  +1.1,  just  a  hair  above  Agree  on 
the  5-point  rating  scale.  The  two  system  managers  as  a  class  agreed  the  most 
strongly  with  this  statement. 

Only  eleven  NOHIMS  users  responded  to  Statement  14,  "scheduling  and 
staffing  patterns  have  been  improved  since  the  advent  of  NOHIMS."  Of  these 
eleven  respondents,  six  either  agreed  or  strongly  agreed  with  the  statement. 

Four  respondents  expressed  a  neutral  opinion,  and  one  individual  disagreed.  The 
overall  average  rating  was  +0.8,  close  to  Agree  on  the  5-point  rating  scale. 

Both  system  managers  as  a  class  strongly  agreed  with  this  statement.  One  data 

entry  clerk  expressed  a  neutral  opinion,  and  the  other  data  entry  clerk 

abstained  from  making  the  rating.  The  medical  care  providers  who  responded  were 
slightly  more  in  agreement  with  this  statement  than  the  industrial  hygienists 
were. 

Of  the  14  NOHIMS  users  who  responded  to  Statement  15,  14  either  disagreed 

or  strongly  disageed  with  the  statement  that  NOHIMS  does  not  benefit  me  much 

personally.  The  overall  average  rating  was  +1.4  for  this  statement, 
enproximately  one-third  of  the  way  from  Disagree  to  Strongly  Disagree.  The  two 
system  managers  as  a  class  disagreed  the  most  strongly  that  NOHIMS  does  not 
benefit  them  much  personally,  followed  by  data  entry  personnel,  and  then 
industrial  hygienists  and  medical  care  providers  equally. 

Of  the  13  NOHIMS  users  who  responded  to  Statement  16,  "worker/patient 
satisfaction  seems  to  be  running  higher  since  NOHIMS  was  introduced,"  seven 
expressed  a  neutral  opinion,  five  ageed  with  the  statement,  and  one  disagreed. 
Those  individuals  expressing  a  neutral  opinion  consisted  of  one  system  manager, 
one  data  entry  clerk,  one  medical  care  provider,  and  four  industrial  hygienists. 
Their  choice  to  remain  neutral  with  regard  to  Statement  16  may  reflect  a  lack  of 
contact  with  the  NOHIMS  worker/patient  population  in  order  to  assess 
satisfaction.  The  overall  average  rating  was  +0.3,  approximately  one-third  of 
the  way  from  Neutral  Opinion  to  Agree  on  the  5-point  rating  scale. 

Thirteen  of  the  14  individuals  responding  to  Statement  17  either  agreed  or 
strongly  agreed  that  they  can  see  how  NOHIMS  can  be  a  boon  to  other  users.  One 
respondent  remained  neutral.  The  overall  average  rating  was  +1.4,  slightly  less 
than  halfway  between  Agree  and  Strongly  Agree.  Data  entry  personnel  agreed  the 
most  strongly  with  this  statement. 

Of  the  14  NOHIMS  users  who  responded  to  Statement  18,  "with  NOHIMS  1  am 
able  to  get  more  done  in  a  day,"  nine  individuals  either  agreed  or  strongly 
agreed  and  five  respondents  expressed  a  neutral  opinion.  The  overall  average 
rating  was  +0.8,  approximately  three-quarters  of  the  way  from  Neutral  Opinion  to 
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Agree.  As  a  NOHIMS  user  class,  the  system  managers  and  data  entry  personnel 
agreed  the  most  strongly  that  they  were  able  to  get  more  done  in  a  day  with 
NOHIMS,  followed  by  medical  care  providers  and  then  industrial  hygienists. 

Ten  of  the  13  individuals  responding  to  Statement  19  either  ageed  or 
strongly  agreed  that  the  records  produced  by  NOHIMS  are  more  amenable  to  review 
and  better  meet  Navy  standards.  Three  respondents  expressed  a  neutral  opinion. 
The  overall  average  rating  was  +1.0,  exactly  at  Agree  on  the  rating  scale.  The 
system  managers  and  data  entry  personnel  agreed  the  most  strongly  with  this 
statement,  followed  by  industrial  hygienists,  and  then  medical  care  providers. 

The  distribution  of  ratings  for  Statement  20,  "the  confidentiality  of  the 
worker 's/patient 's  record  is  more  vulnerable  with  NOHIMS  than  it  was  with  the 
manual  system,"  is  quite  dispersed  with  eight  individuals  in  disagreement,  three 
in  agreement,  and  three  expressing  a  neutral  opinion.  The  overall  average 
rating  was  +0.4,  approximately  one-third  of  the  way  from  Neutral  Opinion  to 
Disagree.  Of  the  three  respondents  agreeing  that  the  confidentiality  of  records 
is  more  vulnerable  with  NOHIMS  than  with  the  manual  system,  two  were  medical 
care  providers  and  one  was  an  industrial  hygienist.  Perhaps  these  three 
individuals  were  reflecting  concern  that  worker/patient  data  are  displayed  on 
the  video  screens  of  terminals,  that  unauthorized  persons  may  be  able  to  access 
worker/patient  data  via  a  terminal  or  special  telephone  number,  or  that 
worker/patient  data  are  stored  in  computer  memory  accessible  to  computer 
operations  personnel.  It  is  generally  assumed  that  the  patient's  paper  record 
is  either  well  protected  in  the  files  of  the  medical  records  room  or  safe  in  the 
custody  of  the  patient's  medical  care  provider.  This  protection  of  privacy  of 
the  paper  record  is  not  always  the  case,  however.  It  may  be  that  potential 
opportunities  to  gain  illicit  access  to  patient  record  data  in  automated 
information  systems  are  more  visible,  and  consequently,  users  are  more  conscious 
of  the  vulnerability  of  the  automated  system  to  violations  of  privacy  than  they 
are  to  the  vulnerability  of  the  paper  record.  Users'  attitudes  concerning  the 
adequacy  of  NOHIMS'  security  features  are  explored  in  more  detail  in  the 
Evaluation  of  System  Design  section  of  this  report. 

Of  the  14  NOHIMS  users  responding  to  Statement  21,  "I  don't  care  much  what 
NOHIMS  costs  to  operate,  we  need  it  to  handle  our  workload  efficiently , "  ten 
individuals  either  agreed  or  strongly  agreed.  Two  people  held  a  neutral  opinion 
and  two  respondents  disagreed.  The  overall  average  rating  was  +0.9  for  this 
statement,  more  than  three-quarters  of  the  way  from  Neutral  Opinion  to  Agree. 

One  system  manager  and  one  industrial  hygienist  were  in  disagreement  with 
Statement  21. 

All  but  one  of  the  14  individuals  responding  to  the  last  statement, 
Statement  22,  either  agreed  or  strongly  agreed  that  if  NOHIMS  were  to  be  taken 
out,  they  would  be  willing  to  make  a  reasonable  effort  to  get  it  back  in 
service.  The  lone  medical  care  provider  who  disagreed  with  this  statement 
appeared  to  be  reacting  to  what  he  considered  a  level  of  austerity  in  his 
department  that  precluded  any  further  cuts.  As  he  commented  along  side  of  his 
rating,  "If  they  cut  anything  else  out,  they  might  as  well  close  the  doors!  We 
are  already  at  bare  bones."  The  overall  average  rating  for  Statement  22  was 
+1.1,  slightly  above  Agree.  Clearly,  the  current  users  of  NOHIMS  at  the  two 
test  sites  value  the  system  and  do  not  want  to  lose  it. 
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Fourteen  individuals  responded  to  22  statements  reflecting  possible 
attitudes  or  opinions  regarding  NOHIMS  performance  by  rating  their  level  of 
agreement  or  disagreement  with  each  statement.  In  general,  respondents  were  in 
agreement  with  12  statements,  disagreed  with  three  statements,  and  showed 
variation  in  their  ratings  of  seven  other  statements. 

NOHIMS  users  on  the  average  agreed  with  the  following  12  statements: 

1.  Worker /patient-related  information  is  more  accessible  and 
available  more  quickly  with  NOHIMS. 

2.  As  a  result  of  NOHIMS,  I  am  able  to  do  a  better  job. 

5.  NOHIMS  catches  more  human  errors  than  the  old  manual  system  did. 

8.  In  general,  NOHIMS  is  better  than  the  old  manual  system  of  record 
keeping. 

12.  I  truly  feel  that  the  quality  of  care  has  been  improved  as  a 
result  of  NOHIMS.  (Half  of  the  respondents,  including  all  five 
medical  care  providers,  agreed;  the  other  half  had  a  neutral 
opinion . ) 

13.  From  an  administrative  point  of  view,  NOHIMS  provides  timely  data 
for  making  management  decisions  that  were  not  available  with  the 
previous  manual  system. 

14.  Scheduling  and  staffing  patterns  have  been  improved  since  the 
advent  of  NOHIMS. 

17.  I  can  see  how  NOHIMS  can  be  a  boon  to  other  users. 

18.  With  NOHIMS,  I  am  able  to  get  more  done  in  a  day. 

19.  The  records  produced  by  NOHIMS  are  more  amenable  to  review  and 
better  meet  Navy  standards. 

21.  I  don't  care  much  what  NOHIMS  costs  to  operate,  we  need  it  to 
handle  our  workload  efficiently. 

22.  If  NOHIMS  were  to  be  taken  out,  I  would  be  willing  to  make  a 
reasonable  effort  to  get  it  back  in  service. 

On  the  average,  NOHIMS  users  disagreed  with  the  following  three 
statements: 

6. 


11. 


In  my  opinion,  NOHIMS  should  not  have  been  implemented  at  this 
activity. 

NOHIMS  has  "goofed"  up  worker/patient  records  more  times  than  I 
care  to  remember. 


15.  NOHIMS  does  not  benefit  me  much  personally. 


For  the  following  seven  statements,  there  was  variation  among  respondents 
in  their  ratings. 

3.  The  performance  of  NOHIMS  falls  short  of  what  I  expected. 

4.  I  could  never  go  back  to  using  the  old  manual  record  system  now 
that  I  have  been  using  NOHIMS. 

7.  I  rarely  have  to  wait  for  necessary  worker/patient  information 
because  the  NOHIMS  system  is  down. 

9.  NOHIMS  has  some  major  problems  that  need  correction. 

10.  If  there  were  budget  cuts  at  this  activity,  I  would  rather  see 
other  services  that  I  need  cut  before  I  lost  NOHIMS. 

16.  Worker/patient  satisfaction  seems  to  be  running  higher  since 
NOHIMS  was  introduced. 

20.  The  confidentiality  of  the  worker's/patient's  record  is  more 
vulnerable  with  NOHIMS  than  it  was  with  the  manual  system. 

We  also  summarized  the  data  from  the  structured  appraisal  of  the 
performance  of  NOHIMS.  We  summed  all  of  the  ratings  by  class  of  NOHIMS  user  and 
then  diviued  this  sum  by  the  total  number  of  statements  rated  by  each  class  to 
arrive  at  an  omnibus  single  average  rating  for  each  user  class.  These  results 
are  presented  in  Table  51 .  The  range  for  this  single  average  rating  was  +2  to 
-2.  The  average  rating  was  positive  for  all  four  classes  of  system  users. 

System  Managers  were  the  most  positive  in  their  omnibus  rating  of  NOHIMS 
performance,  followed  by  data  entry  personnel,  medical  care  providers,  and 
industrial  hygienists.  This  finding  parallels  the  knowledge  of  and  exposure  to 
NOHIMS  experienced  by  these  four  user  classes.  Medical  care  providers  and 
industrial  hygienists  have  the  least  day-to-day  contact  with  the  system,  and  the 
omnibus  average  rating  for  these  two  user  classes  was  the  lowest  and  almost  the 
same. 


We  also  computed  an  omnibus  average  rating  for  all  four  user  classes 
combined.  The  resulting  rating  was  +1.0,  almost  at  +1  on  the  5-point  rating 
scale.  In  the  aggregate,  Table  51  paints  a  picture  of  good  marks  for  the 
performance  of  NOHIMS. 
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SECTION  IV 

OPERATIONAL  TESTING  OF  NOHIMS 


The  operational  testing  of  NOHIMS  was  conducted  in  three  phases: 

(1)  system  integration  testing,  (2)  operational  testing  against  the 
documentation,  and  (3)  performance  testing.  Various  functions  and  tasks  were 
performed  following  the  users'  guides  and  a  performance  testing  plan  that  we 
designed  to  ensure  NOHIMS  functionality.  The  results  of  each  of  these  aspects 
of  operational  testing  are  presented  in  the  three  subsections  below. 


SYSTEM  INTEGRATION  TESTING 

The  integrated  NOHIMS  consists  of:  (1)  two  subsystems  called  components, 
namely,  the  medical  component  and  the  industrial  component,  (2)  system  hardware, 
(3)  the  operating  system,  and  (4)  communications  equipment.  The  integrated 
system  is  different  for  the  Naval  Air  Rework  Facility,  San  Diego  test  site  than 
the  Puget  Sound  Naval  Shipyard,  Bremerton  test  site. 

In  San  Diego,  both  components  of  NOHIMS  reside  on  a  Digital  Equipment 
Corporation  PDP  11/24.  It  has  a  random  access  memory  of  384  megabytes.  The 
system  has  two  System  Industries  hard  disk  drives  with  an  80  megabyte  disk  and 
a  160  megabyte  disk  for  a  total  of  260  megabytes  of  hard  disk  storage  space. 
Communications  equipment  includes  two  Micom  8000  concentrator  modems,  two  Mi  com 
2000  bus  drivers,  and  one  212A  Bell  modem.  Connected  to  this  system  are  three 
Digital  Equipment  Corporation  LA120  printing  terminals,  eight  Televideo  950 
terminals,  a  System  Industries  9800  controller,  and  a  System  Industries  1953 
tape  drive.  The  current  operating  system  is  Digital  Systems  Mumps  (DSM)  Version 
2.0.  Approximately  35  percent  of  the  system's  processing  capability  and  35 
percent  of  the  file  capability  is  used  for  NOHIMS. 

At  Bremerton,  the  industrial  component  of  NOHIMS  resides  on  a  Plessey  11/23 
with  an  80  megabyte  Winchester  hard  disk  drive.  The  only  communications 
equipment  used  is  one  Bell  212A  equivalent  modem.  One  Digital  Equipment 
Corporation  LA120  printing  terminal  and  six  Plessey  VT-100  equivalent  CRT 
terminals  are  connected  to  the  Plessey  11/23.  A  20  megabyte  streaming  cassette 
is  used  for  system  back-ups.  The  operating  system  is  InterSystems  Mumps.  One 
hundred  percent  of  the  system's  processing  capability  is  used  for  NOHIMS.  As  of 
November  1985,  50  percent  of  the  file  capability  was  in  use  for  NOHIMS.  The 
medical  component  is  not  part  of  the  integrated  system  at  the  Puget  Sound  Naval 
Shipyard. 

We  did  not  conduct  system  integration  testing  on  NOHIMS  since  NOHIMS  has 
been  operational  at  two  test  sites  for  the  past  two  to  three  years.  We  felt 
that  documenting  the  actual  experiences  of  testing  and  operating  NOHIMS  in  a 
live  environment  would  be  a  more  thorough  and  accurate  evaluation  of  NOHIMS 
integration  than  any  testing  that  we  could  perform.  We  asked  15  NOHIMS  users  to 
rate  the  performance  of  NOHIMS.  Six  medical  care  providers,  five  industrial 
hygienists,  two  data  entry  clerks,  and  two  system  managers  rated  NOHIMS  in  the 
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areas  of  problems  with  reliability,  downtime,  communication  lines,  and  the  man- 
machine  interface;  magnitude  and  trend  of  noticeable  system  failures; 
acceptability  of  the  number  of  NOHIMS  failures  or  errors;  effect  of  heavy  system 
usage  on  response  time  and  data  entry;  time  required  to  obtain  a  display;  effect 
of  a  NOHIMS  failure  on  the  day-to-day  provision  of  medical  care;  effect  of  a 
NOHIMS  failure  on  the  day-to-day  administration  of  the  Occupational  Health  Unit; 
and,  lastly,  the  number  of  major  "bugs"  in  the  NOHIMS  software.  A  detailed 
discussion  of  their  ratings  and  comments  may  be  found  in  the  Assessment  of  the 
Overall  System  Performance  subsection  of  the  Evaluation  of  NOHIMS  System  Design 
section  of  this  report.  The  following  is  a  summary  of  the  NOHIMS  users'  rating 
of  NOHIMS  performance. 

The  NOHIMS  software  was  considered  reliable  at  the  time  of  our  interviews 
last  fall.  Early  system  downtime  was  due  to  hardware  problems.  There  were  some 
problems  with  communication  lines  in  the  beginning,  but  the  situation  is  fairly 
stable  now.  The  most  significant  problem  mentioned  in  the  man-machine  interface 
was  the  lock  table  problem  that  causes  San  Diego  users  to  be  locked  out  of 
NOHIMS  when  the  PDP  11/24  system  resources  are  stretched  to  capacity.  This 
problem  will  be  resolved  when  the  operating  system  is  upgraded.  All  noticeable 
system  failures  were  attributed  to  hardware  downtime,  power  failures,  and 
problems  with  communication  lines  and  the  modems.  Failures  of  the  NOHIMS 
software  (program  errors)  were  rare.  Most  of  the  users  concurred  that  heavy 
NOHIMS  usage  created  a  system  slowdown  but  of  varying  degrees.  Users  at 
Bremerton  generally  reported  no  effect  on  response  time.  Most  repondents  agreed 
that  data  entry  would  be  delayed  in  varying  amounts  by  slow  system  response  time 
except  three  users  at  Bremerton  who  reported  that  data  entry  is  never  delayed  by 
system  response  time.  Almost  all  of  the  users  felt  that  NOHIMS  displays  either 
came  up  fast  or  somewhat  fast.  The  industrial  component  was  rated  somewhat 
faster  than  the  medical  component.  Almost  three-quarters  of  NOHIMS  users  felt 
that  the  NOHIMS  software  has  no  major  bugs;  the  other  quarter  of  NOHIMS  users 
did  not  report  bugs  of  major  significance. 


Summary 

NOHIMS  has  been  running  in  a  production  mode  in  both  San  Diego  and 
Bremerton  for  a  considerable  length  of  time.  The  system  is  stable  at  both  test 
sites  and  the  majority  of  NOHIMS  users  are  satisfied  with  system  software  and 
hardware  performance,  with  hardware  downtime  being  a  much  more  likely  system 
problem  than  software  program  errors.  System  response  time  can  be  expected  to 
improve  when  NOHIMS  is  migrated  onto  operational  hardware  and  is  running  under 
an  upgraded  MUMPS  operating  system. 


OPERATIONAL  TESTING  AGAINST  THE  DOCUMENTATION 

The  following  are  the  findings  and  conclusions  of  our  evaluation  of  NOHIMS 
operation  against  the  NOHIMS  user  documentation,  namely,  the  NOHIMS  Users' 
Reference  Manual,  the  NOHIMS  System  Manager's  Manual,  the  NOHIMS  User's  Guide, 
and  the  NOHIMS  OHS  Component  System  Maintenance  Manual.  Evaluations  of 
operation  against  the  user  documentation  for  both  the  medical  component  of 
NOHIMS  and  the  industrial  component  of  NOHIMS  are  included  in  this  report.  To 
evaluate  the  medical  component  documentation,  we  had  one  member  of  our 
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I 


•  evaluation  team  read  the  documentation  and  perform  all  of  the  tasks  described  in 

the  operating  manuals.  This  person  was  familiar  with  COSTAR  (the  basis  for  the 
;  medical  component  of  NOHIMS)  prior  to  the  testing,  but  had  not  been  exposed  to 

I  the  adaptations  that  were  made  to  the  medical  component  of  NOHIMS  or  to  its 

!  specific  data  collection  forms.  The  two  people  who  reviewed  the  industrial 

component  documentation  had  no  or  little  exposure  to  the  industrial  component  of 
NOHIMS.  The  reviewers  noted  both  discrepancies  between  the  user  documentation 
and  NOHIMS  operation  and  software  errors  or  other  problems  that  occurred  during 
system  testing. 

i 

Medical  Component  of  NOHIMS 

In  general,  the  user  documentation  for  the  medical  component  of  NOHIMS  is 
informative,  well  written,  easy  to  follow  and  comprehend,  and  complete.  The  use 
of  examples,  exhibits,  and  job  aids  clarifies  specific  data  entry  procedures  and 
informs  the  user  exactly  how  a  screen  or  sequence  df  prompts  should  appear.  The 
sections  of  the  documentation  correspond  to  specific  modules  in  the  NOHIMS 
system,  and  are  arranged  in  the  order  that  the  modules  are  used.  This 
arrangement  not  only  makes  the  manual  an  easy  reference  tool,  but  also  allows 
the  user  to  learn  the  use  of  one  or  more  modules  without  necessarily  having  to 
learn  the  use  of  all  modules  (i.e.,  a  user  may  learn  to  use  the  Registration  and 
Enter  Medical  Data  modules  without  learning  how  to  use  the  COSTAR  Report 
Generator) . 

The  documentation  follows  NOHIMS  operation  closely;  however,  a  number  of 
discrepancies  between  NOHIMS  operation  and  the  user  documentation  were  found. 

All  but  two  are  minor  problems;  simple  corrections  to  the  user  documentation 
would  eliminate  these  minor  discrepancies.  They  have  no  damaging  influence  on 
the  capability  of  a  user  to  operate  NOHIMS.  In  many  instances,  however, 
correction  and/or  clarification  would  make  the  documentation  easier  to  follow 
and/or  would  more  accurately  reflect  NOHIMS  operation. 

The  first  major  problem  that  was  found  is  a  discrepancy  in  the  display 
during  Registration  entry.  At  the  Duty  Station  or  Activity  prompt,  the  Primary 
Clinic  prompt,  and  the  Ethnic  Background  prompt,  the  user  enters  a  number  for 
which  NOHIMS  echoes  back  the  appropriate  description.  The  documentation 
illustrates  the  correct  way  the  screen  shoul  1  display  the  information.  However, 
upon  entry  of  a  number  at  any  one  of  these  p  ompts,  the  system  echoes  back  both 
the  number  and  the  corresponding  description  (i.e.,  "1  Naval  Air  Rework 
Facility"  appears  as  "11  Naval  Air  Rework  F;cility").  This  display  problem 
occurs  only  at  the  entry  prompt;  NOHIMS  does  file  and  retrieve  the  correct 
number  and  display  format.  Therefore,  the  user  should  be  advised  to  overlook 
the  duplication  of  numbers  in  the  display  at  these  three  Registration  prompts  ns 
long  as  the  correct  information  is  shown  in  tie  Patient  Registration  Display,  or 
programming  changes  should  be  made  to  resolve  this  display  problem. 

The  second  major  problem  that  was  encountered  entailed  the  General 
Appearance  section  of  the  Physical  Examination  Findings  (PEX)  encounter  form. 

The  example  illustrated  in  the  documentation  indicates  that  the  General 
Appearance  of  the  patient  was  Normal  and  a  textual  comment  indicates  that  the 
patient  appeared  obese.  In  the  General  Appearance  section  of  the  PEX  form,  the 
only  space  available  for  textual  comments  is  under  the  heading  "If  any 
ABNORMALITIES,  describe:".  This  could  be  confusing  to  a  data  entry  operator 
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unless  the  textual  comment  is  clearly  a  condition  that  the  user  would  know  is 
not  considered  an  abnormality.  Therefore,  it  is  recommended  that  the  space  for 
textual  comments  be  clarified  with  the  heading  "Concise  Comments(*) : "  as  is  done 
in  other  sections  of  the  PEX  form. 

The  minor  problems  that  were  found  in  the  medical  component  documentation, 
along  with  any  recommended  changes,  are  described  below.  They  are  organized  by 
sections  of  the  NOHIMS  Users'  Reference  Manual  and  the  NOHIMS  System  Manager's 
Manual. 


NOHIMS  Users'  Reference  Manual 

Title  Page 

•  Add  "Medical  Component"  to  the  title  page  to  clarify  that  this 
manual  refers  to  the  medical  component  only. 

Contents 

•  On  page  iii,  the  page  number  for  Section  8.  Mailbox  should  be 
"8-1"  instead  of  "81".  [Developers'  Note:  Correction  was  made 
in  June  1986.] 

List  of  Exhibits 

No  problems  were  encountered. 

Section  1.  Introduction  to  COSTAR - The  Medical  Information 

Component  of  NOHIMS 

No  problems  were  encountered. 

Section  2.  NOHIMS  Conventions 

•  On  page  2-3,  the  first  example  of  the  permissible  forms  used  to 
identify  and  select  a  patient  (LAST;)  is  an  invalid  name 
format.  The  fourth  example  (LE,R,;;20)  has  an  extra  comma 
after  the  R  which  needs  to  be  deleted  for  the  example  to  be  a 
valid  name  format. 

Section  3.  Registration 

•  On  page  3-2,  the  words  "Exhibit  1"  should  be  typed  near  the 
bottom  of  the  page  to  make  the  location  consistent  with  other 
exhibits.  Also,  the  Ethnic  Background  field  descriued  in  the 
text  does  not  appear  on  the  form.  This  field  should  be 
included  on  the  Patient  Registration  form.  [Developers'  Note: 
When  the  documentation  was  written  for  the  medical  component  of 
NOHIMS,  Ethnic  Background  was  a  field  on  the  Patient 
Registration  form.  Shortly  after  the  form  was  put  into  use, 
there  was  criticism  of  the  categories  that  had  been  chosen  for 
Ethnic  Background.  This  field  was  temporarily  removed  from  the 
Patient  Registration  form  until  an  acceptable  set  of  ethnic 


categories  could  be  agreed  upon.  A  response  to  the  prompt  was 
made  optional  so  that  it  could  be  skipped  in  Registration  data 
entry.  However,  the  question  mark  response  still  displays  the 
initial  Ethnic  Background  categories.  Description  of  the 
prompt  was  left  in  the  text  of  the  documentation  because  it  was 
expected  that  at  some  point  this  field  would  be  reincorporated 
in  the  system.  To  date  this  has  not  happened.  A  policy 
decision  needs  to  be  made  at  a  higher  level  concerning  a 
standard  breakout  of  Ethnic  Background  categories.  From  a 
research  perspective,  it  is  important  to  collect  this  variable 
so  that  the  incidence  of  disease  in  different  ethnic  groups  can 
be  assessed.] 

•  On  page  3-9,  paragraph  1,  sentence  3,  the  words  "date  of  birth" 
should  be  changed  to  "age". 

Section  4.  Enter  Medical  Data 


•  On  page  4-2,  the  words  "Exhibit  2"  should  be  typed  near  the 
bottom  of  the  page  to  make  the  location  consistent  with  other 
exhibits. 

•  On  page  4-14,  last  paragraph,  it  is  unclear  when  and  how  an 
abnormal  status  code  would  be  entered  preceding  a  Hazardous 
Agent  Surveillance  data  item.  The  text  should  be  changed  to 
clarify  this  entry. 

•  On  page  4-31,  last  paragraph,  sentence  3,  "were"  should  be 
changed  to  "are",  "entered"  should  be  changed  to  "will  enter". 

•  On  page  4-61,  the  words  "Exhibit  16"  and  the  page  number  should 
be  typed  near  the  bottom  of  the  page  to  make  the  location 
consistent  with  other  exhibits. 

•  On  page  4-80,  the  Cynthia  Rigger  example  did  not  work  because 
her  name  and  social  security  number  had  been  changed  in  the 
system.  Her  name  in  the  system  appeared  as  Cynthia  Rigger  and 
her  SSN  was  312-56-7894.  [Developers'  Note:  The  demonstration 
UCI  is  not  frozen  as  a  training  UCI.  Therefore,  display 
examples  may  not  exactly  match  the  system  displays,  although 
formats  will  always  be  the  same.] 

•  On  page  4-82,  "»>  AACQi-D"  should  be  "»>  DSP-D"  to  be 
consistent  with  page  4-74. 

•  It  is  unclear  where  and  when  the  NOHIMS  JOB  AID  FOR  HOBBY 
HAZARDS  is  used.  This  should  be  clarified.  [Developers'  Note: 
The  NOHIMS  JOB  AID  FOR  HOBBY  HAZARDS  is  used  for  data  entry  of 
the  occupational  history.  Documentation  has  not  yet  been 
written  for  entering  occupational  history  data  pending  a  final 
decision  on  the  data  collection  forms.] 
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Section  5.  Display  Medical  Data 


•  On  page  5-6,  code  NBAJ1-N  appears  af ter  code  CBAV2,  not  before. 
[Developers'  Note:  The  demonstration  UCI  is  not  frozen  as  a 
training  UCI.  Therefore,  display  examples  may  not  exactly 
match  the  system  displays,  although  formats  will  always  be  the 
same.  ] 

•  On  page  5-7,  no  administrative  data  appeared  in  the  encounter 
report  for  James  Greeley  on  9/26/84.  Administrative  data  did 
appear  on  other  dates.  [Developers'  Note:  The  administrative 
data  should  be  deleted  from  the  documentation  example.  A 
sentence  should  be  added  to  the  documentation  that  explains 
that  the  Encounter  Report  administrative  variables  are  not 
historically  retained,  therefore,  data  for  administrative  items 
only  appears  in  the  most  recent  encounter  for  the  patient  for 
which  an  item  has  been  entered. 


On  page 
a  "1". 


5-11, 


"NAVAL  AIR  REWORK  FACILITY"  should  be  preceded  by 


•  On  page  5-13,  the  order  of  the  PHYSICAL  EXAMINATION  DATA  AND 
FINDINGS  codes  was  different  in  NOHIMS  than  in  the 
documentation,  although  all  of  the  same  codes  were  displayed. 
[Developers'  Note:  The  demonstration  UCI  is  not  frozen  as  a 
training  UCI.  Therefore,  display  examples  may  not  exactly 
match  the  system  displays,  although  formats  will  always  be  the 
same.  ] 

Section  6.  Print  Medical  Data 


•  On  page  6-1,  "HALT  DAILY  ER  PRINTER"  should  be  "HALT  DAILY 
ENCOUNTER  REPORT  ON  PRINTER".  Also,  "LABORATORY  RESULT 
REPORTING"  should  be  added  to  the  list  of  options. 

•  On  page  6-2,  prior  to  the  prompt  for  OUTPUT  TYPE,  and  on  page 
6-3,  prior  to  the  prompt  for  RESTART  OUTPUT  TYPE,  the  message 
»**#NOTE-BE  SURE  ALL  ENCOUNTERS  HAVE  BEEN  ENTERED  FOR  THIS  DATE 
AND  MONITOR  IS  CAUGHT  UP"  is  displayed.  This  message  should  be 
added  to  the  documentation. 

•  On  page  6-2,  the  BREAK  key  should  be  clarified  as  the  interrupt 
or  Ctrl  C  function. 

•  On  page  6-3,  the  text  after  the  last  prompt  should  be 
identified  as  the  ?  response  to  that  prompt. 

•  On  page  6-9,  after  the  SPECIAL  PRINT  OPTION  prompt,  there 
should  be  a  prompt  for  IDENTIFY  LAST  CORRECTLY  PRINTED  REPORT 
BY  NAME  OR  UNIT  #:>.  Also,  "DEVICE  #4  STARTED"  should  be  "JOB 
STARTED" . 

•  Pages  6-11  through  6-14  should  be  eliminated,  as  the  scheduling 
system  has  not  been  initialized. 


•  If  Laboratory  Result  Reporting  is  a  viable  option,  a  subsection 
should  be  added  to  explain  the  use  of  this  option. 

•  All  subsections  should  be  completely  capitalized,  instead  of 
being  a  mixture  of  upper  and  lower  case  letters.  All 
subsections  in  other  sections  are  completely  capitalized. 

[Developers'  Note:  Since  no  programming  changes  were  made  to  the 
Print  Medical  Data  module,  the  public  domain  COSTAR  documentation 
for  this  module  was  used  for  the  NOHIMS  documentation.  It  is 
known  that  discrepancies  exist  between  the  public  domain 
documentation  and  the  public  domain  software  because  the  software 
was  modified  further  after  the  documentation  was  written. ] 

Section  7.  Report  Generator 

No  problems  were  encountered. 

Section  8.  Mailbox 


•  On  page  8-5,  the  BREAK  key  should  be  clarified  as  the  interrupt  or 
Ctrl  C  function. 

•  On  page  8-10,  "See  commands  on  page  7"  should  be  changed  to  "See 

commands  on  page  8-9". 

[Developers'  Note:  Since  no  programming  changes  were  made  to  the 
Mailbox  module ,  the  public  domain  COSTAR  documentation  for  this 
module  was  used  for  the  NOHIMS  documentation.  It  is  known  that 
discrepancies  exist  between  the  public  domain  documentation  and  the 
public  domain  software. ] 


NOHIMS  System  Manager’s  Manual 
Title  Page 

•  Add  "Medical  Component"  to  the  title  page  to  clarify  that  this 
manual  only  refers  to  the  medical  component. 

No  other  problems  encountered  in  the  manual. 


Industrial  Component  of  NOHIMS 

The  user  documentation  for  the  industrial  component  of  NOHTMS  is  also 
informative  and  well  organized.  Again,  the  sections  of  the  documentation 
correspond  to  specific  modules  in  the  NOHIMS  system,  and  are  arranged  in  the 
order  the  modules  are  used.  This  documentation,  however,  utilizes  few  examples 
which,  if  included,  could  clarify  data  entry  procedures.  Because  there  are  few 
data  entry  examples,  the  operational  instructions  are  often  cryptic  and 
difficult  to  follow  for  a  novice  NOHIMS  user.  The  industrial  component  often 
automatically  proceeds  from  one  module  to  anotier  module  during  data  entry  which 
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is  not  explained  in  the  documentation.  Therefore,  the  documentation  for  the 
industrial  component  of  NOHMIS  is  not  as  easy  to  follow  and  comprehend  as  the 
documentation  for  the  medical  component  of  NOHIMS.  Areas  of  function  that  would 
be  especially  amenable  to  detailed  examples  are  noted  below. 

As  in  the  case  of  the  medical  component,  a  number  of  discrepancies  between 
the  documentation  and  NOHIMS  operation  were  found.  Most  of  the  problems  are 
minor  and  can  be  easily  corrected,  such  as  the  numerous  typographical  errors 
found  throughout  the  manual.  The  problems  found  are  as  follow,  by  chapters  of 
the  NOHIMS  User's  Guide  and  the  NOHIMS  OHS  Component  System  Maintenance  Manual. 
Only  those  typographical  errors  essential  to  the  organization  of  the  manual  have 
been  documented  here. 


NOHIMS  User's  Guide 


•  Add  "Industrial  Component"  to  the  title  page  to  clarify  that  it 
refers  to  only  the  industrial  component  of  NOHIMS. 

Table  of  Contents 


•  In  Chapter  6,  Section  6.8  should  be  "DISPLAY  AND  REVIEW 

ENVIRONMENT  DATA",  found  on  page  6-4.  The  current  Section  6.8 
should  be  changed  to  6.9  and  the  current  Section  6.9  should  be 
changed  to  6.10. 


Chapter  1.  Introduction 


No  problems  encountered. 


Chapter  2. 


NOHIMS 


•  On  page  2-2,  Section  2.5,  number  3,  the  [ / ]  character  should  be 
clarified  as  being  the  Delete  or  Rubout  key. 


Chapter  3.  NOHIMS  Functions 


•  On  page  3-1,  "TRANSACTION/MESSAGE  PROCESS"  should  be  added  to 
the  list  of  options,  and  should  be  explained  if  it  is  a  viable 
option. 


•  On  page  3-2,  under  B.  PERSONNEL  DATA,  the  suboptions  "TRAINING 
HISTORY"  and  "SAFETY  EQUIPMENT"  should  be  added  to  the 
documentation  or  they  should  be  deleted  from  the  option  driver, 
f Developers'  Note:  These  options  were  never  implemented  in 
NOHIMS.  They  will  be  deleted  from  the  option  driver.] 

•  On  page  3-2,  the  option  "TRANSACTION/MESSAGE  PROCESS"  should  be 
added,  with  bhe  suboptions  "RECEIVED  MESSAGE  PROCESSING", 
"TRANSMIT/MESSAGE  PREPARATION",  and  "PERSONNEL  TRANSACTION 
PROCESSING". 
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•  On  page  4-3,  last  paragraph,  if  the  initial  definition  process 
is  necessary  at  any  time  other  than  during  OHS  System 
implementation,  there  should  be  an  explanation  and  example  of 
how  the  procedure  is  done.  [Developers'  Note:  The  initial 
definition  process  is  always  accomplished  during  system 
implementation.  Deleting  the  word  "usually"  from  the  text  will 
make  this  clearer.] 

•  On  page  4-4,  under  edit  options,  "QUIT"  should  be  changed  to 
"QUIT  EDIT  MENU",  "EDIT  AGENCY  DATA  ITEMS"  should  be  changed  to 
"EDIT  FACILITY  DATA  ITEMS".  [Developers’  Note;  The  word 
"agency"  is  used  generi rally  in  the  documpntation .  The  system 
will  use  the  term  that  is  appropriate  for  the  industry  such  as 
"facility"  or  "company."] 

•  On  page  4-4,  under  item  1,  "Agency  Name"  should  be  changed  to 
"Full  Name",  "Generic  Title"  should  be  changed  to  "Generic 
Title  for  the  Industry",  and  "Agency  Type"  should  be  changed  to 
"Industry  Type".  [Developers'  Note:  The  terms  used  here  were 
intended  to  simply  describe  the  data  items  and  not  duplicate 
the  prompts  exactly.] 

Chapter  5.  Personnel  Function 

•  On  page  5-1,  paragraph  2  under  Section  5.2,  the  normal  agency 
unit  method  should  be  clarified. 

•  On  page  5-2,  at  the  last  Item  #  or  Quit>  prompt,  "[Q]"  should 
be  added  as  a  possible  response. 

•  On  page  5-3,  in  the  transaction  option  list  under  Section  5.4, 
the  word  "ENVIRONMENT"  in  option  numbers  2,  3,  and  4  should  be 
changed  to  "WORKPLACE".  In  the  last  paragraph,  second 
sentence,  i:  should  be  clarified  whether  the  environment 
assignments  are  terminated  automatically  by  the  system  or 
whether  the  user  needs  to  terminate  them. 

•  On  page  5-4,  the  list  of  subfunctions  should  include  "0=QUIT" 
and  "7=DISPLAY  EXAMINATION  DATA".  The  current  "7"  should  be 
changed  to  "8"  and  "8"  should  be  changed  to  "9". 

•  In  trying  to  use  the  EXAM  ROSTER  PRINT  function,  it  was  unclear 
what  the  Report  File  #  was  and  where  the  user  should  obtain  it 
(one  of  many  places  in  the  documentation  where  examples  showing 
prompt  sequences  and  appropriate  user  responses  would  be 
helpful) . 


•  On  page  5-5,  the  occupation  codes  are  clearly  explained,  but  it 
is  unclear  where  the  data  entry  operator  would  obtain  a 
patient's  occupation  code  for  entry. 
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Chapter  6.  Environment  Function 

•  On  page  6-3,  in  the  option  list,  "QUIT"  should  be  changed  to 
"QUIT  ENVIRONMENT  SELECTION",  "AGENCY"  should  be  changed  to 
"FACILITY",  "A"  should  be  deleted  from  option  numbers  2  and  3, 
and  "AN"  should  be  deleted  from  option  numbers  1  and  4.  In  the 
fourth  paragraph,  "1  or  2"  should  be  changed  to  "2  or  3". 

[ Developers'  Note:  The  word  "agency"  is  used  generically  in 
the  documentati  .m.  The  system  will  use  the  term  that  is 
appropriate  f the  industry  such  as  "facility"  or  "company."] 

•  On  page  6-4,  the  DISPLAY  AND  REVIEW  ENVIRONMENT  DATA  section 
should  be  numbered  "6.8",  not  "6.6". 

•  On  page  6-5,  the  EDIT  ENVIRONMENTS  section  should  be  numbered 
"6.9",  not  "6.8". 

•  On  page  6-6,  the  ASSIGNING  ENVIRONMENTS  section  should  be 
numbered  "6.10",  not  "6.9". 

Chapter  7.  Survey  Data  Function 

•  On  page  7-1,  paragraph  1  under  7.2,  it  is  unclear  whether  the 
three  types  of  surveys  are  entered  the  same  or  differently.  An 
example  of  survey  data  entry  is  necessary  here. 

•  On  page  7-2,  paragraph  10  states  that  a  general  textual  comment 
is  solicited  under  Adverse  Health  Effects  Reported.  A  space 
for  text  was  not  found  on  the  IHS  Form  on  page  E-l . 

Chapter  8.  Hazardous  Material  Function 

•  On  page  8-4,  it  is  unclear  where  the  data  entry  operator 
obtains  the  NIOSH  method  number  and  the  type  of  standard  for 
data  entry. 

Chapter  9.  Query  Function 

•  No  problems  encountered  with  the  documentation.  This  section 
contained  examples  of  data  entry  and  reports  that  were  very 
helpful  in  understanding  the  operation  of  this  module. 

Chapter  10.  Personnel  Transaction  File  Processing 

•  On  page  10-1,  in  the  first  paragraph  after  the  list  of 
operations,  "option  1  or  2  above"  should  be  changed  to  "option 
2  or  3  above".  Under  MESSAGE  protocol,  it  should  be  clarified 
how  the  user  can  determine  if  a  terminal  device  has  been 
programmed  for  this  protocol. 

•  On  page  10-2,  the  number  10.2  should  be  followed  by  the  section 
heading  of  "TRANSACTION  PROCESSING". 


•  If  RECEIVED  MESSAGE  PROCESSING  and  TRANSMIT/MESSAGE  PREPARATION 
are  viable  options,  each  of  these  should  be  explained. 


Appendices 

The  appendices  should  be  arranged  in  the  order  they  are 
referenced  in  the  text.  Currently,  Appendix  A  is  the  first  one 
referenced  on  page  5-5,  then  Appendix  E  is  the  next  one 
referenced  on  page  7-1. 

Appendix  D  is  referenced  on  page  8-4  under  Scale.  The  examples 
listed  on  page  8-4  (PPM,  MG/M3,  DBA)  should  be  included  in 
Appendix  D.  The  table  looks  as  if  it  contains  codes  for  media 
not  units. 

Page  E-l  should  be  identified  as  Appendix  E  at  the  top  of  the 
page. 

NOHIMS  OHS  Component  System  Maintenance  Manual 

No  problems  were  encountered  in  the  sections  that  have  been  written  thus 
far. 


Summary 

Although  this  report  documents  in  detail  the  discrepancies  found  between 
the  user  documentation  and  NOHIMS  operation,  most  problems  are  minor,  and  simple 
corrections  or  additions  to  the  user  documentation  would  clarify  the  processes 
for  the  user.  On  the  whole,  the  user  documentation  was  found  to  be  informative 
and  well  written.  With  the  information  provided  in  the  manuals,  the  user  will 
be  capable  of  utilizing  all  of  the  operational  and  functional  aspects  of  NOHIMS. 
|  It  is  essential,  however,  that  more  examples  of  data  entry  be  added  to  the 

NOHIMS  User’s  Guide  for  the  industrial  component. 


SYSTEM  PERFORMANCE  TESTING 

From  the  deficiencies  and  requirements  laid  out  in  the  NOHIMS  Mission 
Element  Needs  Statement  (MENS)  and  the  NOHIMS  System  Decision  Paper,  we  compiled 
a  list  of  functions  that  NOHIMS  should  have  in  order  to  meet  the  Navy  functional 
description  for  NOHIMS.  Under  each  function  we  defined  tasks  for  NOHIMS  to 
perform  to  determine  if  NOHIMS  adequately  met  that  functional  requirement.  We 
would  like  to  note  that  many  of  the  functions  are  very  broad  in  scope.  For 
these  functions  we  performed  one  or  more  tasks  designed  to  demonstrate  the  kinds 
of  tasks  NOHIMS  can  perform  in  the  area  of  that  function.  NOHIMS  may  or  may  not 
meet  specific  functional  needs  once  they  are  defined  by  the  Navy.  Many  of  the 
tasks  were  performed  in  the  process  of  conducting  the  operational  testing  of 
NOHIMS.  The  results  of  the  system  performance  testing  done  in  the  demonstration 
UCIs  are  as  follows.  The  results  are  organized  by  function  and  then  by  task 
under  the  function. 


* 
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Function  1:  Ability  to  input,  store,  retrieve,  and  display  selected 
workplace  monitoring  data  including  work  history  data,  data  on  exposure 
episodes,  environmental  monitoring  and  industrial  hygiene  data,  and 
demographic  data.  Specific  functions  to  include:  (1)  retrieval  of 
exposure  parameters  by  location  or  hazard  type,  (2)  provision  of 
historical  data  on  exposures  for  individual  workers  or  a  cohort,  and 
(3)  demonstration  of  past  and  present  levels  of  workplace  exposures  for 
compliance  with  NAVOSH  standards. 


Task  A:  Create,  edit,  and  display  personnel  data  (work  history 
and  demographic  data)  for  selected  individuals. 

RESULTS:  Using  the  Personnel  Data  Entry  option,  an  imaginary 
worker  named  John  Q.  Worker  was  entered  into  the  system.  He  was 
assigned  to  the  hull  repair  department  and  Bldg.  1,  Room  100, 
Office.  Using  the  Edit  Personnel  Data  option,  his  date  of  birth 
was  changed.  The  personnel  data  for  John  Q.  Worker  and  another 
imaginary  worker  named  Carol  P.  Jones  were  displayed.  These  data 
included  demographic  data  and  workplace  assignments.  At  present, 
only  current  workplace  assignments  can  be  displayed.  No  problems 
were  encountered. 


Task  B:  Create,  edit,  and  display  survey  data  for  selected 
surveys. 

RESULTS:  Using  the  Survey  Data  Entry  option,  data  from  a  survey 
of  Bldg.  1,  Room  100  was  entered  into  the  system.  One 
Occupational  Hazard  Data  Sheet  for  asbestos  was  entered  and 
asbestos  was  added  to  the  materials  inventory  for  the  shop.  The 
supervisor  and  telephone  for  the  shop  and  the  measurement  value 
for  the  asbestos  were  edited.  The  Industrial  Hygiene  Survey  form, 
Occupational  Hazard  Data  Sheet,  and  the  Materials  Inventory  for 
the  survey  were  displayed.  No  problems  were  encountered. 

Task  C:  Generate  a  report  that  shows  historical  exposure  data  for 
selected  individuals;  for  a  group  of  individuals. 

RESULTS:  NOHIMS  does  not  currently  have  a  capability  to  retrieve 
historical  exposure  data  from  the  industrial  component.  The  only 
way  to  get  historical  exposure  data  would  be  to  generate  a  COSTAR 
Report  Generator  report  that  would  retrieve  past  examinations  for 
hazardous  agents  and  infer  that  these  were  the  patient’s 
exposures.  This  would  not  provide  information  about  actual  levels 
of  exposures.  An  alternative  would  be  to  permanently  store  the 
Individual  Exposure  Examination  Report  (IEER)  that  is  generated 
each  year  at  the  time  of  the  individual's  annual  examination 
report.  The  IEER  contains  exposure  data  for  the  individual  as  of 
the  month  they  are  due  for  a  physical.  A  third  alternative  would 
be  to  augment  the  Interactive  Query  function  in  the  industrial 
component  with  the  ability  to  retrieve  historical  exposure  data. 


Task  D:  Generate  a  report  that  shows  past  and  present  workplace 
exposures  for  a  selected  environment. 


RESULTS:  Using  the  Environment  Data  option,  the  personnel 
assigned  to,  the  surveys  done  on,  the  materials  located  in,  and 
the  most  current  measurement  value  for  the  materials  present  in 
shop  Bldg.  1,  Room  100,  Office  were  displayed.  NOHIMS  will  not 
display  past  workplace  exposures.  No  problems  were  encountered. 

Task  E:  Generate  a  report  that  shows  exposure  measurements  and 
persons  exposed  for  a  selected  agent. 

RESULTS:  Using  the  Query /Report  module  in  the  industrial 
component  of  NOHIMS,  a  report  that  listed  the  workers  who  are 
exposed  to  asbestos  and  the  latest  exposure  measurement  for 
asbestos  for  each  environment  that  contains  asbestos  was 
generated.  Three  workers  in  two  environments  were  displayed.  No 
problems  were  encountered. 


Function  2t  Ability  to  input,  store,  retrieve,  and  display  selected 
occupational  health  data,  including  preplacement/employment  physical 
examinations,  medical  surveillance  examinations,  job  certification 
examinations,  injury/illness  care,  fitness  for  duty  and  return  to  work 
interactions,  audiometric  data,  biomedical  monitoring  data,  and  basic 
medical  and  demographic  data. 

Task  A:  Create,  edit,  and  display  a  medical  encounter  for  a 
preplacement/employment  physical  examination,  a  medical 
surveillance  examination,  a  job  certification  examination,  a 
fitness  for  duty  interaction,  and  a  return  to  work  interaction. 
(Note:  A  medical  encounter  may  contain  medical  data,  demographic 
data,  and  biomedical  monitoring  data.) 

RESULTS:  A  periodic  examination  for  an  imaginary  patient  named 
James  C.  Greeley  was  entered  into  NOHIMS.  His  encounter  included 
work  information,  hazardous  agent  surveillance  data,  laboratory 
tests  ordered,  physical  examination  findings,  problems,  and  a 
disposition.  Demographic  data  had  been  previously  entered  using 
Patient  Registration.  Separate  encounters  for  all  of  the 
categories  above  were  not  entered  because  the  procedures  are  the 
same  for  all  of  the  types  of  examinations.  Medical  edit  entries 
were  made  for  two  imaginary  patients,  Jason  P.  Pilot  and  Cynthia 
T.  Rigger.  Codes  were  added  to  encounters,  textual  comments  were 
edited,  textual  comments  were  deleted,  textual  comments  were 
added,  codes  were  deleted,  and  laboratory  and  physical  examination 
results  were  edited.  Encounter  reports  for  James  C.  Greeley, 

Jason  P.  Pilot,  and  Cynthia  T.  Rigger  were  displayed.  No  problems 
were  encountered. 

Task  B:  Create,  edit,  and  display  a  medical  encounter  for  injury 
and  illness  care. 


RESULTS:  NOHIMS  does  not  currently  have  encounter  forms  or 
directory  codes  for  entering  illness/in jury  care. 

Task  C:  Enter  and  display  data  for  an  audiogram. 


RESULTS:  Two  audiograms  were  entered  into  NOHIMS  for  an  imaginary 
patient  named  Chester  Cowrey.  One  audiogram  was  a  reference 
audiogram  and  the  other  was  a  follow-up  audiogram.  The  standard 
Hearing  Conservation  Data  forms  (DD  2215  and  DD  2216)  with 
plastic  overlays  containing  data  entry  codes  were  used  to  enter 
these  data.  The  Lab  Results  option  was  used  to  edit  the  date  of 
the  reference  audiogram  for  the  follow-up  audiogram.  The 
audiogram  data  were  retrieved  as  part  of  a  periodic  examination 
Encounter  Report  display  and  as  part  of  the  summary  reports — the 
Status  Report  and  the  Patient  Summary.  No  problems  were 
encountered. 

Task  D:  Demonstrate  utilization  of  historical  Hearing 
Conservation  Management  Information  System  (HECMIS)  data. 

RESULTS:  NOHIMS  does  not  have  a  direct  interface  with  historical 
HECMIS  data.  The  audiogram  data  stored  in  NOHIMS  are  entered 
using  the  data  collection  forms  from  the  HECMIS  database  ensuring 
compatibility  with  the  historical  database.  However,  special 
programming  is  required  to  directly  link  the  two  databases. 


Function  3:  Identification  of  individuals  exposed  to  hazards  in  the 
workplace  and  the  level  of  exposure. 

Generate  a  list  of  individuals  exposed  to  a  selected  hazard  and 
the  level  of  exposure. 

RESULTS:  See  Function  1,  Task  E. 


Function  4:  Identification  of  exposed  or  potentially  exposed  individuals 
requiring  physical  examinations  for  all  hazards. 

Generate  an  Occupational  Health  Roster  and  a  Notification  of 
Individual  Exposures  for  selected  individuals. 

RESULTS:  Us  ing  the  Hazard/Examination  Report  option,  an 
Occupational  Health  Roster  and  Physical  Examination  Notification 
Reports  for  personnel  due  for  a  physical  examination  in  September 
1986  were  generated.  No  problems  were  encountered. 

Function  5l  Provision  of  exposure  history,  current  exposures,  and  a  list 
of  recommended  tests  and  procedures  to  medical  personnel. 

Task  A:  Generate  an  Individual  Exposure  Examination  Report  for 
selected  individuals. 
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RESULTS:  Using  the  Hazard/Examination  Report  option,  all  workers 
who  were  due  for  a  physical  examination  in  March  1986  were 
selected  and  Individual  Exposure  Examination  Reports  were 
produced  for  each  worker  selected.  No  problems  were  encountered. 

Task  B:  Generate  a  Patient  Data  Sheet  for  selected  individuals. 

RESULTS:  A  Patient  Summary  report  was  generated  for  imaginary 
patients  James  C.  Greeley,  Chester  Cowrey,  and  Industrial  Worker. 
This  report  contained  summary  medical  data  across  encounters  and 
current  exposure  data  obtained  from  the  industrial  component.  No 
problems  were  encountered. 


Function  6t  Provision  of  medical  job  certifications  to  line  authorities. 

Generate  a  medical  job  certification  form  for  selected 
individuals. 

RESULTS:  NOHIMS  does  not  generate  a  medical  certification 
form.  Because  virtually  every  worker  examined  is  returned  to 
work,  the  medical  care  providers  simply  note  the  worker's  return 
time  on  the  Physical  Examination  Notification  Report  and  send  the 
worker  back  to  the  job.  If  the  worker's  disposition  is  other  than 
a  return  to  full  duty,  the  physician  contacts  the  work  supervisor 
directly,  usually  by  telephone. 


Function  7:  Provision  of  composite  summaries  of  medical  and  exposure  data 
to  higher  authorities,  including  summaries  of  work  force  physical 
examination  results. 

Task  A:  Generate  a  report  containing  the  number  of  people  exposed 
to  selected  substances  during  a  selected  time  period. 

RESULTS:  See  Function  1,  Task  C. 

Task  B:  Generate  a  report  containing  the  number  of  people  with 
an  abnormal  test  finding  during  a  selected  time  period;  the  number 
of  people  with  an  abnormal  physical  examination  during  a  selected 
time  period. 

RESULTS:  Using  the  COSTAR  Report  Generator  in  the  medical 
component,  a  list  of  patients  who  had  a  Differential  test  with  an 
abnormal  result  during  March  1,  1986  through  March  8,  1986  was 
generated.  The  list  included  the  patient's  name,  date  of  visit, 
and  the  abnormal  Differential  result.  A  list  of  patients  with  an 
abnormal  heart  examination  during  March  1986  was  also  produced. 
This  list  contained  the  patient's  name,  date  of  visit,  and  the 
modifier(s)  for  the  portion(s)  of  the  heart  examination  that 
was(were)  abnormal.  No  problems  were  encountered. 
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Function  8:  Incorporation  or  replacement  of  existing  central  Asbestos 
Medical  Surveillance  Program  (AMSP)  and  Hearing  Conservation  Management 
Information  System  (HECMIS)  data  and  utilization  of  historical  data. 

Task  A:  Create,  edit,  and  display  an  asbestos  surveillance 
encounter . 

RESULTS:  An  asbestos  surveillance  encounter  for  James  C.  Greeley 
was  entered  into  NOHIMS  using  data  provided  in  the  NOHIMS  User's 
Reference  Manual.  The  standard  Navy  Asbestos  Medical  Surveillance 
Program  form  (NAVMED  6260/5)  with  plastic  overlays  containing  data 
entry  codes  was  used  to  enter  these  data.  The  Medical  Edit  option 
was  used  to  edit  the  age  the  worker  began  smoking.  The  asbestos 
data  were  retrieved  as  a  separate  Encounter  Report  display  and  as 
part  of  the  summary  reports — the  Status  Report  and  the  Patient 
Summary.  There  is  no  linkage  with  historical  data  although  the 
same  data  items  are  collected.  No  problems  were  encountered. 

Task  B:  Create,  edit,  and  display  hearing  conservation  data. 

RESULTS:  See  Function  2,  Tasks  C  and  D. 


Function  9;  Provision  of  summary  data  for  reports  to  higher  authorities 
and  administrative  proceedings,  including  workload  summaries. 

Generate  the  COSTAR  Report  Generator  reports  in  the  medical 
component  that  provide  data  for  the  6260/1  semi-annual  report, 
namely,  ACTIVITY6260,  CIVMIL6260,  HAZARD6260,  J0B6260,  LAB6260, 
LABTEST6260,  RADIOLOG Y6260,  TYPE6260C,  and  TYPE62bOM. 

RESULTS:  All  of  these  reports  were  run  on  subsets  of  patient 
records  defined  by  date  of  encounter.  No  problems  were 
encountered.  The  NOHIMS  reports  do  not  produce  the  data  in  the 
same  format  as  required  for  the  6260/1  semi-annual  report, 
however;  manual  transfer  of  data  to  the  standard  report  is 
necessary.  These  NOHIMS  reports  provide  tallies  of  physical 
examinations  done  and  laboratory  and  radiology  tests  conducted. 
NOHIMS  d  oes  not  keep  track  of  manpower.  These  reports  are  used  to 
count  procedures  performed  and  examinations  conducted.  NOHIMS 
does  not  tally  any  workload  parameters  in  the  industrial 
component,  such  as  number  of  surveys  conducted  during  a  given  time 
period , 


Function  10s  Ability  to  input,  store,  process,  and  display  occupational 
health  program  management  data  to  include  manpower,  time-in-motion, 
equipment  lists,  inspection  requirements,  and  other  appropriate  resource 
data  required  to  track  and  direct  manpower,  equipment,  and  budget 
resources. 

NOHIMS  does  not  track  any  of  these  kinds  of  data.  NOHIMS  will 
provide  tallies  of  medical  procedures  performed,  as  described  in 
Function  9. 


Function  lit  Compilation  of  standardized  information  on  exposures  and 
health  for  short-term  and  long-term  epidemiologic  analysis  and  other 
research  purposes. 

The  NOHIMS  function  tested  in  Function  12,  Task  B  can  generate 
standardized  data  for  various  laboratory  tests  and  certain 
physical  examination  results  for  exposed  workers  that  are  suitable 
for  epidemiologic  analysis  and  research  purposes.  Although  NOHIMS 
collects  a  multitude  of  other  standardized  data  suitable  for 
epidemiologic  analysis,  new  software  to  extract  and/or  manipulate 
these  data  will  most  likely  be  required. 


Function  12s  Correlation  of  exposure  data  with  medical  data  such  as 
summary  data  on  the  extent  of  disease  and  injury  by  hazard  type  and  work 
location. 

Task  A:  Generate  a  report  that  correlates  diagnosis  with  hazard 
type  and  work  location. 

RESULTS:  We  created  a  COSTAR  Report  Generator  report  in  the 
medical  component  of  NOHIMS  that  tallies  diagnoses  by  two 
hazardous  agent  surveillances,  mercury  and  carbon  monoxide,  for 
Building  32415.  This  report  creates  tables  of  the  frequency  of 
all  diagnosis  codes  for  each  of  the  hazard  agent  surveillances. 
Since  there  is  no  function  that  retrieves  data  from  the  medical 
component  and  industrial  component  simultaneously,  there  is  no 
existing  way  to  correlate  diagnosis  with  actual  exposure 
measurements. 

Task  B:  Generate  selected  laboratory  test  result  data  for 
individuals  exposed  to  selected  agents  for  use  in  other 
statistical  packages. 

RESULTS:  Using  the  CONSTRUCT  SSN  GLOBAL  and  PRODUCE  FIXED  LENGTH 
RECORDS  options  in  the  COSTAR  Report  Generator  module  of  the 
NOHIMS'  medical  component,  we  selected  patients  who  had  an 
encounter  between  January  1,  1986  and  January  10,  1986.  We  then 
produced  fixed-length  records  that  contained  results  for  any 
Pulmonary  Function  tests  these  people  had  during  the  same  time 
period.  The  fixed-length  record  contains  limited  patient 
identifying  data,  limited  demographic  data  (age,  sex,  and  ethnic 
background),  date  of  the  test,  COSTAR  code  of  the  test,  and 
results  of  the  test.  Next,  we  used  the  MOVE  SSNS  FROM  INDUS  UCI 
option  to  transfer  a  list  of  17  social  security  numbers  that  had 
been  selected  in  the  industrial  component  and  merge  them  with  a 
list  of  two  patient  social  security  numbers  in  the  medical 
component.  We  then  produced  fixed-length  records  that  contained 
results  from  any  Differential  and/or  Pulmonary  Function  tests  that 
these  people  had.  No  problems  were  encountered.  We  did  not  test 
transferring  the  fixed-length  records  to  tape. 
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Function  13:  Provision  of  accurate  medical  and  exposure  information  on 
individuals  for  use  in  legal  functions,  including  Workers'  Compensation 
and  environmental  differential  pay  determinations. 

Task  A:  Generate  a  list  of  historical  workplace  assignments  and 
the  exposures  at  each  workplace  for  a  selected  individual. 

RESULTS:  A  listing  of  the  current  workplace  and  hazardous 
exposures  for  a  given  individual  may  be  obtained  using  the 
Query/Report  module.  NOUIMS  does  not  presently  have  a  capability 
for  retrieving  historical  data  from  the  industrial  component 
database.  See  Function  1. 

Function  14:  Compatibility  and  linkage  with  other  suitable  databases 
where  possible,  for  example,  military  personnel /pay  systems,  TRIMIS,  etc. 
Access  to  and  display  of  information  from  other  databases  such  as 
hazardous  material  information  systems,  and  Federal,  1X)D,  or  Navy 
standards  and  instructions. 

Task  A:  Demonstrate  compat  ibilil  with  other  suitable  databases 
where  possible,  for  example,  mil  tary  personne 1 /pay  systems, 
TRIMIS,  etc. 

RESULTS:  The  personnel  data  contained  in  the  industrial  component 
of  NOUIMS  are  obtained  from  the  Personnel  Extract  File  ensuring 
compatibility  between  the  two  systems.  Compatibility  between 
NOHIMS  and  TRIMIS  cannot  be  demonstrated  as  the  development  of 
TRIMIS  has  not  proceeded  far  enough  to  make  a  comparison. 

Task  B:  Demonstrate  linkage  with  suitable  databases  such  as 
military  personnel/pay  systems,  TRIMIS,  etc. 

RESULTS:  NOHIMS  does  not  have  any  direct  links  with  other  Navy 
databases.  It  has  an  indirect  link  with  military  personnel/pay 
systems  because  the  Personnel  Extract  File  is  loaded  onto  tape  and 
reloaded  into  NOHIMS  on  a  monthly  basis  to  update  NOHIMS  personnel 
files.  We  did  not  test  this  specific  link  because  this  task  has 
been  done  at  the  San  Diego  test  site  for  30  months.  No  linkage 
problems  are  encountered  during  routine  transfers  of  data  to 
NOHIMS. 

Task  C:  Test  interfaces  with  other  information  databases  such  as 
hazardous  material  information  systems,  and  Federal,  DOD,  or  Navy 
standards  and  instructions. 

RESULTS:  NOHIMS  does  not  currently  have  interfaces  with  other 
information  databases. 
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Summary 

The  industrial  component  of  NOHIMS  provides  the  capabilities  necessary  to 
input,  store,  edit,  retrieve,  and  display  various  workplace  monitoring  data, 
including  work  history  data,  data  on  exposure  episodes,  environmental  monitoring 
and  industrial  hygiene  data,  and  worker  demographic  data.  It  is  limited  to 
retrieving  and  displaying  current  data  such  as  present  exposures  and  workplace 
assignments.  Historical  data  for  many  variables  are  retained  in  the  industrial 
component's  data  files,  although  at  present  these  data  cannot  be  retrieved. 

The  medical  component  of  NOHIMS  provides  functions  for  entering,  storing, 
editing,  retrieving,  and  displaying  occupational  health  data,  including  data 
from  preplacement/employment  physical  examinations,  medical  surveillance 
examinations,  job  certification  examinations,  fitness  for  duty  and  return  to 
work  interactions,  audiometric  data,  biomedical  monitoring  data,  and  basic 
medical  and  demographic  data.  It  does  not  have  a  capability  for  entering 
illness  and  injury  care  data.  However,  the  Naval  Health  Research  Center  is 
currently  developing  data  collection  forms  and  making  changes  to  the  COSTAR 
directory  to  allow  illness  and  injury  care  data  to  be  processed  by  NOHIMS. 

NOHIMS  has  functions  for  entering  and  displaying  Hearing  Conservation  Management 
Information  System  (HECMIS)  audiogram  data.  NOHIMS  does  not  have  a  direct 
interface  with  the  HECMIS  database.  NOHIMS  also  incorporates  data  from  the 
Asbestos  Medical  Surveillance  Program. 

Both  components  have  limited  capabilities  for  storing  and  processing 
occupational  health  program  management  data.  The  medical  component  of  NOHIMS 
can  provide  tallies  of  various  process  measures  such  as  the  number  of  physical 
examinations  conducted  and/or  the  number  of  laboratory  tests  performed.  NOHIMS 
can  provide  composite  summaries  of  various  medical  and  exposure  data,  although 
the  industrial  component  is  limited  to  retrieving  current  values.  NOHIMS 
collects  a  multitude  of  standardized  data  suitable  for  epidemiologic  analysis; 
however,  the  software  to  extract  and/or  manipulate  these  data  is  limited.  There 
is  no  function  in  NOHIMS  that  retrieves  data  from  the  medical  and  industrial 
components  simultaneously.  NOHIMS  does  have  a  few  links  between  the  two 
components.  The  Patient  Summary  in  the  medical  component  displays  current 
exposure  information.  Also,  social  security  numbers  from  the  industrial 
component  can  be  used  to  select  patients  in  the  medical  component  for 
reformatting  of  data  using  the  fixed-length  record  options.  An  individual's 
current  exposures  and  workplace  assignments  can  be  retrieved  from  the  database 
for  use  in  legal  functions;  however,  NOHIMS  presently  cannot  retrieve  historical 
exposures  or  workplace  assignments.  NOHIMS  has  compatibility  with  military 
personnel/pay  systems  such  as  the  the  Personnel  Extract  File  produced  by  the 
Naval  Air  Rework  Facility.  NOHIMS  does  not  have  any  direct  links  with  other 
Navy  or  outside  databases. 
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SECTION  V 

EVALUATION  OF  USES  OF  NOHIMS 


NOHIMS  and  its  database  may  be  used  for  a  variety  of  purposes  in  addition 
to  the  basic  functions  of  workplace  monitoring  and  medical  surveillance.  We 
evaluated  the  usefulness  of  NOHIMS  in  four  other  areas:  the  assessment  of 
medical  monitoring  and  care,  legal  evidence  for  compensation  claims  and  other 
legal  purposes,  epidemiologic  research,  and  administrative  functions.  To  assess 
the  uses  of  NOHIMS  in  medical  monitoring  and  care,  we  questioned  the  medical 
care  providers,  NHRC  NOHIMS  developers,  and  the  higher  level  managers  about  the 
goals  for  NOHIMS  in  the  area  of  medical  monitoring  and  care.  We  also  described 
ways  in  which  reports  generated  by  NOHTMS  could  be  used  in  monitoring  medical 
surveillance.  To  evaluate  the  usefulness  of  NOHIMS  as  a  database  for  legal 
evidence,  we  questioned  employees  involved  with  compensation  claims  at  the  Naval 
Air  Rework  Facility  (NARF),  San  Diego;  compensation  specialists  at  the  Naval 
Hospital,  San  Diego;  and  Navy  legal  counsel  at  the  Naval  Legal  Services  Office 
of  the  Naval  Station,  San  Diego;  the  Labor  Relations  and  Litigation  Branch, 

Naval  Air  Station,  North  Island,  San  Diego;  and  the  Office  of  Counsel,  Naval  Air 
Rework  Facility,  Alameda,  California  about  areas  in  which  the  NOHIMS  database 
will  be  useful  as  legal  evidence  and  the  types  of  data  required  for  these 
purposes.  We  questioned  the  NOHIMS  developers  at  the  Naval  Health  Research 
Center  (NHRC)  in  order  to  determine  the  usefulness  and  adequacy  of  NOHIMS  as  an 
aid  to  epidemiologic  research.  Finally,  we  interviewed  the  test  site 
administrators,  higher  level  managers,  and  the  NHRC  NOHIMS  developers  about  the 
usefulness  of  NOHIMS  in  administrative  functions. 


ASSESSMENT  OF  USEFULNESS  OF  NOHIMS  IN  MEDICAL  MONITORING  AND  CARE 

The  evaluation  of  the  usefulness  of  NOHIMS  in  medical  monitoring  and  care 
has  two  parts.  The  first  subsection  describes  the  results  of  our  interviews 
with  the  NHRC  NOHIMS  developers,  medical  care  providers,  and  industrial 
hygienists.  In  these  interviews,  we  asked  each  of  the  interviewees  to  identify 
the  medical  monitoring  and  care  goals  for  NOHIMS  and  we  questioned  them  with 
regard  to  how  they  perceived  NOHIMS  had  influenced  medical  monitoring  and  care. 
The  second  subsection  describes  ways  that  NOHIMS  could  be  used  to  assess  medical 
monitoring  and  care  in  the  operational  environment. 


Evaluation  of  Medical  Monitoring  and  Care  Goals 

Based  on  resource  materials  from  oilier  evaluations  of  medical  information 
systems,  we  devised  a  list  of  medical  monitoring  and  care  goals  to  use  in 
assessing  the  goals  for  NOHIMS  and  how  well  the  goals  were  being  met.  These 
goaLs  fell  into  five  broad  categories:  improvement  in  quality  of  care, 
improvement  in  access  to  care,  improvement  in  resource  utilization,  improvement 
in  management  aspects  of  health  care,  and  improvement  in  compliance  with 
monitoring  programs/Navy  set  standards  of  rare.  Using  this  list  of  goals,  we 
asked  the  respondents  to  identify  their  percept  ion  of  the  specific  goals  for 
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NOHIMS  in  the  area  of  medical  monitoring  and  care;  how  well  NOHIMS  was  meeting 
these  goals;  the  specific  goals  NOHIMS  was  not  meeting  well;  the  effect  of 
NOHIMS  on  quality  of  care,  access  to  care,  resource  utilization,  and  compliance 
with  monitoring  programs;  and  reasons  for  the  effects  that  NOHIMS  had  on  medical 
monitoring  and  care.  We  questioned  the  medical  care  providers  with  regard  to 
the  effect  of  the  availability  of  the  NOHIMS  medical  record  and  the  availability 
of  the  individual's  exposure  history  on  the  quality  of  patient  care.  In 
addition,  we  asked  the  medical  care  providers  and  industrial  hygienists  to 
evaluate  the  effect  of  NOHIMS  on  communication  between  industrial  hygienists  and 
medical  personnel.  The  industrial  hygienists  also  evaluated  how  NOHIMS  had 
affected  communication  between  industrial  hygienists/safety  specialists  and  work 
center  supervisors.  We  interviewed  four  NHRC  NOHIMS  developers,  six  medical 
care  providers,  and  five  industrial  hygienists.  The  list  of  goals  and  the 
questions  that  we  used  in  these  interviews  may  be  found  in  Component  23  of 
Appendix  A. 


Table  52  shows  the  specific  goals  for  NOHIMS  that  the  NHRC  NOHIMS 
developers  and  the  medical  care  providers  identified.  None  of  the  goals  was 
mentioned  by  all  of  the  respondents;  however,  eight  out  of  nine  of  the 
respondents  (89%)  mentioned  three  goals.  These  were  improvement  in  database 
acquisition,  problem  identification,  and  research  information  collection.  The 
next  most  frequently  mentioned  goals  were  improvement  in  record  accuracy, 
communication,  patient  follow-up,  record  availability,  medical  reports, 
compliance  with  periodic  physical  examinations,  and  compliance  with  the  asbestos 
surveillance  program,  all  of  which  were  mentioned  by  78  percent  of  the 
respondents.  The  remaining  goals  were  all  mentioned  by  44  percent  or  more  of 
the  respondents,  but  to  varying  degrees. 


The  goals  that  the  developers  mentioned  differed  somewhat  from  those 
mentioned  by  the  medical  care  providers.  Generally,  a  higher  percentage  of  the 
medical  care  providers  mentioned  the  quality  of  care  and  access  to  care  goals 
than  did  the  NHRC  NOHIMS  developers.  Conversely,  generally  a  higher  percentage 
of  the  NRHC  NOHIMS  developers  mentioned  the  goals  in  the  areas  of  resource 
utilization,  management  aspects  of  health  care,  and  compliance  with  monitoring 
programs/Navy  set  standards  of  care  than  did  the  medical  care  providers.  This 
difference  is  probably  a  reflection  of  the  varying  perspective  of  these  two 
groups  on  how  the  system  will  be  used. 


Table  53  presents  the  respondents'  assessment  of  how  well  NOHIMS  is  meeting 
the  medical  and  monitoring  care  goals.  All  of  the  respondents  felt  that  NOHIMS 
was  meeting  the  goals  at  least  somewhat  well,  and  half  of  the  respondents  rated 
NOHIMS  as  meeting  them  very  well.  The  NHRC  NOHIMS  developers  gave  NOHIMS 
somewhat  better  ratings  on  meeting  the  goals  than  did  the  medical  care 
providers. 


Table  54  shows  the  specific  goals  that  the  respondents  said  NOHIMS  was  not 
meeting  well.  The  goal  that  was  mentioned  most  frequently  as  one  NOHIMS  was  not 
meeting  well  was  improvement  in  management  and  operations,  mentioned  by  38 
percent  of  the  respondents.  Improvement  in  quality  of  care,  improvement  in 
compliance  with  monitoring  programs,  and  improvement  in  resource  utilization 
were  mentioned  by  only  25  percent  of  those  responding  to  the  question. 


The  NHRC  NOHIMS  devel  oper  who  chose  i mprovement  in  quality  of  care  as  a 
goal  that  NOHIMS  was  not  meeting  selected  this  goal  because  despite  the  system's 
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TABLE  52 

Specific  Goals  for  NOHIMS  in  the 
Area  of  Medical  Monitoring  and  Care 
(Number  who  mentioned  goal;  multiple  answers  allowed) 

NHRC  %  of 

NOHIMS  Higher  Level  Total  Who 

Developers _ Managers _ TOTAL _ Answered 


Improvement  of 
quality  of  care  via: 


Patient  management: 

diagnostic  tests  2 

database  acquisition  3 

treatment  planning  2 

problem  identification  3 

feedback  to  physician 
regarding  acheivement 
of  desired  outcome  2 

Patient  compliance  with 
physician  orders  because 
of  comprehensiveness/ 
continuity  of  care  1 

Quality  of  care  review 

procedures  2 

Research  information 

collection  3 

Training  activities  2 

Record  accuracy  2 

Earlier  diagnosis  of 

abnormal  conditions  1 

Earlier  notification  of 

patient  abnormalities  1 

Communication  3 

Automated  medical  testing  0 


Improvement  of 
access  to  care  via: 


Patient  follow-up  3 
Appointment  scheduling  2 
Record  contents  2 
Record  availability  3 
Visit  registration  2 
Medical  reports  3 


4  6  67 

5  8  89 

4  6  67 

5  8  89 


4 


6  67 


3  4  44 

4  6  67 

5  8  89 

3  5  56 

5  7  78 


4  5  56 

4  5  56 

4  7  78 

4  4  44 


4  7  78 

4  6  67 

4  6  67 

4  7  78 

4  6  67 

4  7  78 


(Continued) 
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TABLE  52  (CONT. ) 


NHRC 

%  of 

NOHIMS 

Higher  Level 

Total  Who 

Developers 

Managers 

TOTAL 

Answered 

Improvement  of 
resource  utilization  via: 


Health  manpower  utili¬ 
zation/availability  3 

Patient  services: 

fewer  unnecessary  visits  3 
fewer  redundant 

laboratory  tests  3 

better  referral  2 

Improvement  of  management 
aspects  of  health  care  via: 


Provision  of  data  and 
analytical  tools  for: 
utilization  review 

procedures  2 

manpower  scheduling  3 

budgeting  and  planning  2 

long-range  manpower 

planning  2 

long-range  facility 

planning  2 

regional/Navy-wide 

health  planning  3 

Administrative  reports  3 


Improvement  in  compliance 
with  monitoring  programs/Navy 
set  standards  of  care: 

Periodic  physical 

examinations  4 

Protective  equipment  1 

Asbestos  surveillance 

program  4 


1  4  44 

2  5  56 

2  5  56 

2  4  44 


2  4  44 

2  5  56 

2  4  44 

2  4  44 

2  4  44 


3  6  67 

3  6  67 


3  7  78 

3  4  44 

3  7  78 


TOTAL  WHO  ANSWERED 


4 


5 


9 


100 


No  Comment 


0 


1 


TOTAL  INTERVIEWED  4 


6 


10 
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TABLE  53 

Assessment  of  How  Well  NOHIMS  Is  Meeting 
the  Medical  Monitoring  and  Care  Goals 
(Number  who  mentioned  rating) 


NHRC 

NOHIMS 

Developers 

Medical 

Care 

Providers 

TOTAL 

%  of 

Total  Who 
Answered 

Very  well 

2 

2 

4 

50 

Well* 

1 

0 

1 

12 

Somewhat  well 

0 

3 

3 

38 

Somewhat  not  well 

0 

0 

0 

0 

Not  well 

0 

0 

0 

0 

TOTAL  WHO  ANSWERED 

3 

5 

8 

100 

No  Comment 

1 

1 

2 

TOTAL  INTERVIEWED 

4 

6 

10 

*  Category  added  by  respondent 
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TABLE  54 

Specific  Goals  That  NOHIMS  Is  Not  Meeting  Well 
(Number  who  mentioned  goal;  multiple  answers  allowed) 


NHRC 

NOHIMS 

Developers 

Medical 

Care 

Providers 

TOTAL 

%  of 

Total  Who 
Answered 

Improvement  in: 

Management  and 
operations 

0 

3 

3 

38 

Quality  of  care 

1 

1 

2 

25 

Compliance  with 

monitoring  programs 

2 

0 

2 

25 

Resource  utilization 

1 

1 

2 

25 

Access  to  care 

0 

0 

0 

0 

TOTAL  WHO  ANSWERED 

3 

5 

8 

100 

No  Comment 

1 

1 

2 

TOTAL  INTERVIEWED 

4 

6 

10 
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"great  potential  for  improving  all  aspects  of  patient  care  and  management,"  he 
has  concern  about  whether  physicians  will  actually  use  the  system  to  its  full 
advantage  in  clinical/care  decisions.  He  felt  that  this  was  a  problem  of 
implementation  and  not  design,  however.  This  developer  also  commented  that 
NOHIMS  needs  to  evolve  in  the  area  of  management  aspects  of  health  care.  Tn  his 
opinion,  NOHIMS  has  not  been  used  much  in  this  area,  although  he  predicts  that 
this  will  be  a  significant  use  for  NOHIMS  in  the  future.  Two  of  the  NHRC  NOHIMS 
developers  identified  improvement  in  compliance  with  monitoring  programs  as  an 
area  of  weakness.  One  of  these  developers  thought  that  NOHIMS  was  not  "doing 
much  about  compliance"  with  protective  equipment  because  there  was  no  feedback 
to  supervisors  if  a  worker  was  not  wearing  his  protective  equipment.  The  other 
developer  felt  that  NOHIMS  had  not  fully  improved  compliance  with  monitoring 
programs  because  the  implementation  of  the  respiratory  programs  and  job 
certification  programs  was  not  complete.  [These  programs  have  since  been 
included  into  NOHIMS  criteria  for  physical  examinations.]  The  NHRC  NOHIMS 
developer  who  mentioned  that  NOHIMS  was  not  meeting  resource  utilization  goals 
felt  that  NOHIMS  users  were  not  fully  utilizing  the  system’s  capabilities  in 
this  area,  probably  because  of  a  lack  of  training  on  the  part  of  the  users. 

The  medical  care  providers  as  a  group  mentioned  three  areas  of  goals  that 
NOHIMS  is  not  meeting  well.  These  included  management  and  operations  goals 
mentioned  by  three  out  of  five  (60%)  of  the  medical  care  providers,  and  quality 
of  care  goals  and  resource  utilization  goals  each  mentioned  by  one  of  the 
medical  care  providers.  Two  of  the  three  medical  care  providers  who  mentioned 
management  and  operations  goals  commented  that  NOHIMS  was  not  providing  all  of 
the  management  reports  that  were  needed.  The  medical  care  providers  who 
mentioned  other  goals  NOHIMS  was  not  meeting  did  not  amplify  as  to  why  NOHIMS 
was  not  meeting  these  other  goals. 

The  medical  care  providers  did  have  some  general  comments  with  regard  to 
the  usefulness  of  NOHIMS  in  medical  monitoring  and  care.  One  medical  care 
provider  stated  that  there  was  a  problem  with  "people  thinking  of  the  system  not 
as  a  minimum  but  as  an  absolute."  He  himself  often  augments  the  list  of  tests 
to  be  performed  because  of  [the  patient's]  lifestyle,  hobbies,  etc.  Another 
medical  care  provider  who  did  not  identify  any  particular  goals  that  NOHIMS  is 
not  meeting  well  felt  that  there  has  been  "some  improvement  [in  medical 
monitoring  and  care]  but  nowhere  near  the  potential.”  A  third  medical  care 
provider  felt  that  "concerns  about  currency  and  accuracy  of  information 
dictate  the  usefulness  of  the  system."  Also,  this  provider  thought  that 
NOHIMS'  usefulness  was  limited  by  not  having  integrated  industrial  hygiene  and 
medical  data.  For  example,  he  would  like  to  identify  everyone  with  an  abnormal 
chest  X-ray  and  asbestos  exposure.  One  of  the  occupational  health  technicians 
who  did  not  identify  a  particular  goal  that  NOHIMS  was  not  meeting  mentioned 
having  a  problem  with  patients  reporting  different  exposures  than  NOHIMS, 
confusion  over  protective  equipment  examination  tallies,  and  some  patients 
reporting  that  they  were  never  notified  of  their  scheduled  examination.  [The 
problem  with  the  protective  equipment  tallies  was  resolved  since  that  Lime. J 

Tables  55-58  show  how  the  respondents  rated  the  effect  of  NOHIMS  on  quality 
of  care,  access  to  care,  resource  utilization,  and  compliance  with  monitoring 
programs.  Seventy-one  percent  of  those  who  responded  to  the  question  about  the 
effect  of  NOHIMS  on  quality  of  care  felt  that  NOHLMS  had  increased  the  quality 
of  care  (see  Table  55).  One  of  the  medical  care  providers  stated  that  the 
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Increased  quality 
Maintained  quality 
Decreased  quality 


TABLE  55 

Effect  of  NOHIMS  on  Quality  of  Care 
(Number  who  mentioned  rating) 


NHRC 

NOHIMS 

Developers 

Medical 

Care 

Providers 

TOTAL 

%  of 

Total  Who 
Answered 

3 

2 

5 

71 

0 

0 

0 

0 

0 

0 

0 

0 

Mixed  effect* 


0 


2 


2 


29 


NOHIMS  data  collection  forms  manage  the  physician's  behavior,  thereby  making 
their  physical  examinations  more  complete. 

Two  of  the  medical  care  providers  (29%  of  the  respondents)  stated  that 
NOHIMS  had  a  mixed  effect  on  the  quality  of  care.  One  of  these  medical  care 
providers  explained  that  NOHIMS  had  a  mixed  effect  on  the  quality  of  patient 
care  because  "some  people  previously  not  caught  are  examined,  but  now  others  are 
falling  through  the  cracks."  The  other  medical  care  provider  was  very  excited 
about  the  Individual  Exposure  Examination  Report  and  its  influence  on  the 
quality  of  care  provided.  On  the  down  side,  however,  he  complained  that  the 
system  does  not  contain  data  on  illness/injury  care  and  that  maintaining  a  dual 
system  (old  manual  system  and  NOHIMS)  takes  much  of  the  occupational  health 
technicians'  time  away  from  patient  care.  He  felt  that  when  the  Navy  eliminated 
the  need  to  maintain  both  systems,  NOHIMS  would  have  a  more  positive  effect  on 
the  quality  of  patient  care. 

Eighty-three  percent  of  the  respondents  stated  that  NOHIMS  had  increased 
access  to  care,  although  three  of  the  medical  care  providers  felt  that  they 
could  not  comment  on  this  issue  (see  Table  56).  Negative  comments  centered 
around  the  concern  that  NOHIMS  was  "still  losing  some  [who  required  an 
examination] ." 

Table  57  shows  that  all  of  the  respondents  felt  that  NOHIMS  had  increased 
resource  utilization.  One  specific  comment  was  that  the  "physicians  are 
learning  to  use  the  industrial  hygiene  data  more." 

Although  86  percent  of  the  respondents  felt  that  NOHIMS  had  increased 
compliance  with  monitoring  programs  (see  Table  58),  there  were  varying  opinions 
on  whether  NOHIMS  was  adequately  identifying  those  who  needed  examinations. 

One  occupational  health  technician  felt  that  they  were  catching  more  of  the 
people  who  required  asbestos  or  hearing  examinations.  One  of  the  physicians,  on 
the  other  hand,  was  concerned  that  NOHIMS  was  not  identifying  all  people 
requiring  audiometric  tests  and  that  some  "wanderers"  (people  who  move  from 
location  to  location  in  their  job)  were  being  missed.  This  care  provider  also 
made  the  comment  that  "industrial  hygiene  surveillance  is  not  up-to-date  so  I  am 
not  confident  to  deny  an  examination  to  workers  based  on  NOHIMS  [data]  if  the 
worker  comes  in  of  his  own  accord." 

Table  59  shows  what  the  NHRC  NOHIMS  developers  and  medical  care  providers 
identified  as  the  reasons  for  the  effect  of  NOHIMS  on  the  medical  monitoring  and 
care  goals.  The  two  reasons  that  were  mentioned  most  frequently  were  increased 
availability  of  the  medical  record  and  availability  of  patient-specific  summary 
reports,  both  of  which  were  mentioned  by  86  percent  of  the  respondents.  More 
appropriate  services  provided  (mentioned  by  71%  of  the  respondents),  improved 
communication  between  departments  (71%),  and  improved  appointment  scheduling 
(71%)  were  mentioned  next  most  frequently.  Eight  other  reasons  were  mentioned 
but  to  a  lesser  degree.  The  percentage  of  NHRC  NOHIMS  developers  mentioning  a 
particular  reason  was  similar  to  the  percentage  of  medical  care  providers 
mentioning  the  reason  with  the  exception  of  increased  patient  care  services 
provided  and  improved  follow-up  of  patients  with  abnormal  findings  or  tests. 
Three  out  of  four  (75%)  of  the  medical  care  providers  who  responded  felt  that 
there  were  increased  patient  care  services  provided  while  none  of  the  NHRC 
NOHIMS  developers  selected  this  reason  for  the  effect  of  NOHIMS.  Conversely, 
all  three  of  the  NHRC  NOHIMS  developers  who  responded  to  this  question  felt  that 
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TABLE  56 

Effect  of  NOHIMS  on  Access  to  Care 
(Number  who  mentioned  rating) 


NHRC 

NOHIMS 

Developers 

Medical 

Care 

Providers 

TOTAL 

%  of 

Total  Who 
Answered 

Increased  access 

3 

2 

5 

83 

Maintained  access 

0 

0 

0 

0 

Decreased  access 

0 

0 

0 

0 

Mixed  effect* 

0 

1 

1 

17 

TOTAL  WHO  ANSWERED 

3 

3 

6 

100 

No  Comment 

1 

3 

4 

TOTAL  INTERVIEWED 

4 

6 

10 

*  Category  added  by  respondent 


TABLE  57 

Effect  of  NOHIMS  on  Resource  Utilization 
(Number  who  mentioned  rating) 


NHRC 

NOHIMS 

Developers 

Medical 

Care 

Providers 

TOTAL 

1  of 

Total  Who 
Answered 

Increased  utilization 

3 

3 

6 

100 

Maintained  utilization 

0 

0 

0 

0 

Decreased  utilization 

0 

0 

0 

0 

TOTAL  WHO  ANSWERED 

3 

3 

6 

100 

No  Comment 

1 

3 

4 

TOTAL  INTERVIEWED 


4 


6 


10 
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TABLE  58 

Effect  of  NOHIMS  on  Compliance  with  Monitoring  Programs 
(Number  who  mentioned  rating) 


NHRC 

NOHIMS 

Developers 

Medical 

Care 

Providers 

TOTAL 

%  of 

Total  Who 
Answered 

Increased  compliance 

2 

4 

6 

86 

Maintained  compliance 

1 

0 

1 

14 

Decreased  compliance 

0 

0 

0 

0 

TOTAL  WHO  ANSWERED 

3 

4 

7 

100 

No  Comment 

1 

2 

3 

TOTAL  INTERVIEWED 

4 

6 

10 
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TABLE  59 

Reasons  for  Effect  of  NOHIMS  on  Medical  Monitoring  and  Care  Goals 
(Number  who  mentioned  reason;  multiple  answers  allowed) 


NHRC 

Medical 

7o  of 

NOHIMS 

Care 

Total  Who 

Developers 

Providers 

TOTAL 

Answered 

Increased  availability 
of  the  medical  record 

3 

3 

6 

86 

Availability  of  patient- 
specific  summary  reports 

3 

3 

6 

86 

More  appropriate 
services  provided 

3 

2 

5 

71 

Improved  communication 
between  departments 

3 

2 

5 

71 

Improved 

appointment  scheduling 

2 

3 

5 

71 

Availability  of 
on-line  look-up  of 
patient-specific  data 

2 

2 

4 

57 

Increased  patient  care 
services  provided 

0 

3 

3 

43 

Improved  follow-up  of 
patients  with  abnormal 
findings  or  tests 

3 

0 

3 

43 

More  accurate 
medical  records 

1 

2 

3 

43 

Availability  of 
user-defined  reports 

1 

1 

2 

29 

Earlier  diagnosis  and 
notification  of  problems 

1 

1 

2 

29 

Improved 

manpower  scheduling 

0 

1 

1 

14 

Improved  quality  of 
care  review  procedures 

0 

1 

1 

14 

there  had  been  improved  follow-up  of  patients  with  abnormal  findings  or  tests. 
None  of  the  medical  care  providers  selected  this  reason  for  the  effect  of  NOHIMS 
on  medical  monitoring  and  care. 

Table  60  presents  how  the  medical  care  providers  rated  the  effect  of  the 
availability  of  an  accurate  medical  record  on  the  quality  of  patient  care.  Four 
out  of  the  five  medical  care  providers  who  made  this  rating  felt  that  NOHIMS  had 
a  very  beneficial  effect.  A  fifth  medical  care  provider  thought  that  NOHIMS  had 
the  potential  to  be  very  beneficial  in  this  area.  The  sixth  provider  did  not 

feel  he  could  comment  on  this  issue  since  he  had  never  actually  used  the 

electronic  record. 

In  Table  61  we  see  that  83  percent  of  the  medical  care  providers  felt  that 
the  availability  of  the  individual's  exposure  history  at  the  time  of  the 
physical  examination  was  very  beneficial.  One  medical  care  provider  said  that 
the  effect  was  only  somewhat  beneficial  because  too  often  exposures  are 
incomplete  or  exposures  are  not  measured  at  all. 

The  last  two  tables  in  this  subsection  show  data  from  questions  about  the 

effect  of  NOHIMS  on  communication  between  selected  groups  of  people.  Table  62 
shows  how  the  medical  care  providers  and  industrial  hygienists  rated  NOHIMS  with 
regard  to  the  effect  on  communication  between  these  two  groups.  Overall,  67 
percent  of  those  who  responded  to  the  question  felt  that  NOHIMS  had  improved 
communication  and  33  percent  thought  that  communication  between  industrial 
hygienists  and  medical  personnel  had  been  maintained.  All  five  of  the 
industrial  hygienists  gave  NOHIMS  a  rating  of  improving  communication.  Their 
reasons  for  these  ratings  centered  around  the  feeling  that  the  physicians  were 
initiating  more  contact  with  the  industrial  hygienists  generally  by  asking 
questions  and  around  the  availability  of  reports  generated  by  NOHIMS.  One 
industrial  hygienist  felt  that  the  medical  care  providers  and  industrial 
hygienists  were  working  together  more,  providing  increased  opportunities  for 
interaction. 

Generally,  the  medical  care  providers  were  less  satisfied  with  the 
communication  between  the  industrial  hygienists  and  medical  personnel.  As  one 
medical  care  provider  perceived  it,  there  was  more  communication  between  medical 
care  providers  and  industrial  hygienists  because  of  errors  and  discrepancies  in 
the  data  from  NOHIMS,  but  the  quality  of  the  communication  was  no  different  than 
before.  Two  medical  care  providers  complained  that  they  were  not  getting 
feedback  from  the  industrial  hygienists  on  follow-up  of  exposures  reported  by 
the  patients.  Also,  one  medical  care  provider  wanted  to  know  what  surveys  are 
scheduled,  including  where  and  when  they  are  scheduled. 

We  next  asked  the  industrial  hygienists  to  assess  the  effect  of  NOHIMS  on 
the  communication  between  the  industrial  hygieni sts/saf ety  specialists  and  work 
center  supervisors.  We  wanted  to  also  discuss  this  issue  with  some  work  center 
supervisors.  We  asked  individuals  at  the  NARF  Safety  Office  if  they  could 
identify  some  work  center  supervisors  for  us  to  interview  about  the 
communication.  These  individuals  felt,  however,  that  none  of  the  work  center 
supervisors  really  knew  of  NOHIMS.  Since  the  only  NOHIMS  product  a  work  center 
supervisor  comes  in  direct  contact  with  is  the  Physical  Examination  Notification 
Report,  they  are  largely  unaware  of  NOHIMS  and  its  operation.  Table  63  shows 
that  four  out  of  five  of  the  industrial  hygienists  (80%)  felt  that  communication 
between  the  industrial  hygieni sts/saf ety  specialists  and  the  work  center 


TABLE  60 

Effect  of  the  Availability  of  an  Accurate  Medical  Record 
on  the  Quality  of  Patient  Care 

According  to  the  Medical  Care  Providers 
(Number  who  mentioned  rating) 

TOTAL 

%  of 

Total  Who 
Answered 

Very  beneficial 

4 

80 

Somewhat  beneficial 

0 

0 

No  effect 

0 

0 

Somewhat  detrimental 

0 

0 

Very  detrimental 

0 

0 

Other:  potential 
to  be  very 
beneficial 

1 

20 

TOTAL  WHO  ANSWERED 
No  Comment 
TOTAL  INTERVIEWED 


TABLE  61 

Effect  of  the  Availability  of  an  Individual's  Exposure  History 
at  the  Time  of  the  Physical  Examination 

According  to  the  Medical  Care  Providers 
(Number  who  mentioned  rating) 

TOTAL 

%  of 

Total 

Interviewed 

Very  beneficial 

5 

83 

Somewhat  beneficial 

1 

17 

No  effect 

0 

0 

Somewhat  detrimental 

0 

0 

Very  detrimental 

0 

0 

TOTAL  INTERVIEWED 
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TABLE  62 


Effect  of  NOHIMS  on  Communication  Between 
Industrial  Hygienists  and  Medical  Personnel 
(Number  who  mentioned  rating) 

Medical 

Care 

Providers 

Industrial 

Hygienists 

TOTAL 

%  of 

Total  Who 
Answered 

Improved  communication 

1 

5 

6 

67 

Maintained  communication 

3 

0 

3 

33 

Deteriorated  communication  0 

0 

0 

0 

TOTAL  WHO  ANSWERED 

4 

5 

9 

100 

No  Comment 

2 

0 

2 

TOTAL  INTERVIEWED 

6 

5 

11 

TABLE  63 

Effect  of  NOHIMS  on  Communication  Between 
Industrial  Hygienists/Safety  Specialists  and  Work  Center  Supervisors 
According  to  the  Industrial  Hygienists 
(Number  who  mentioned  rating) 

%  of 
Total 

TOTAL _ Interviewed 

Improved  communication  4  80 

Maintained  communication  1  20 


Deteriorated  communication 


0 


0 


< 

I 


supervisors  had  improved  and  that  one  industrial  hygienist  (20%)  felt  that 
communication  had  been  maintained.  The  industrial  hygienists'  comments  explain 
their  point  of  view.  One  industrial  hygienist  felt  that  NOHIMS  had  forced  the 
industrial  hygienists  to  spend  more  time  in  the  field.  Another  reported 
satisfaction  with  "being  able  to  answer  queries  [from  the  work  center 
supervisors]  rapidly."  Three  of  the  industrial  hygienists  thought  that  having 
reports  from  NOHIMS  had  improved  the  communication  between  industrial  hygienists 
and  work  center  supervisors.  One  of  the  industrial  hygienists  described  being 
able  to  "sit  down  with  the  work  center  supervisor,  go  over  last  year's  survey, 
and  decide  [together]  what  this  year's  survey  should  cover  using  a  urintout  of 
the  previous  year's  survey."  Two  of  the  hygienists  reported  having  more 
accurate  or  complete  data  to  communicate  with  the  work  center  supervisors. 


* 


Summary 

Improvement  in  database  acquisition,  problem  identification,  and  research 
information  collection  were  the  medical  and  monitoring  care  goals  for  NOHIMS 
that  were  mentioned  most  frequently  by  the  respondents.  These  were  each 
mentioned  by  89  percent  of  those  responding  to  this  question.  Seventy-eight 
percent  of  the  people  who  identified  medical  monitoring  and  care  goals  for 
NOHIMS  selected  improvement  in  record  accuracy,  communication,  patient  follow¬ 
up,  record  availability,  medical  reports,  compliance  with  periodic  physical 
examinations,  and  compliance  with  the  asbestos  surveillance  medical  program. 

All  of  the  respondents  thought  that  NOHIMS  was  meeting  the  medical 
monitoring  and  care  goals  at  least  somewhat  well;  50  percent  rated  NOHIMS  as 
meeting  them  very  well.  The  goal  that  was  mentioned  most  frequently  as  a  goal 
that  NOHIMS  was  not  meeting  well  was  improvement  in  management  and  operations 
which  was  mentioned  by  38  percent  of  the  respondents.  The  only  complaint  about 
NOHIMS  that  was  repeated  significantly  was  that  NOHIMS  should  be  providing  more 
data/reports.  The  interviewees  also  reported  general  problems  with  accuracy  of 
the  system.  Specific  examples  included  concern  over  patient  reports  of 
exposures  versus  NOHIMS  reports  of  exposures,  incomplete  survey  data,  and 

specific  categories  of  people  requiring  examinations  being  overlooked  by  the  | 

system  (since  resolved). 

Seventy-one  percent  of  those  who  responded  to  the  questions  felt  that 
NOHIMS  had  increased  quality  of  care,  83  percent  felt  that  NOHIMS  had  increased 
access  to  care,  100  percent  rated  NOHIMS  as  increasing  resource  utilization,  and 
86  percent  felt  that  NOHIMS  had  increased  compliance  with  monitoring  programs.  | 

The  main  reasons  that  the  interviewees  identified  for  these  effects  were  the 
increased  availability  of  the  medical  record  and  availability  of  patient- 
specific  summary  reports  (both  mentioned  by  86%  of  the  respondents),  more 
appropriate  services  provided  (71%),  improved  communication  between  departments 
(71%),  and  improved  appointment  scheduling  (71%).  1 

! 

Eighty  percent  of  the  medical  care  providers  said  that  the  availability  of  j 

an  accurate  medical  record  with  NOHIMS  had  a  very  beneficial  effect  on  the  1 

quality  of  patient  care.  Eighty-three  percent  of  the  providers  felt  that  the  ! 

availability  of  the  individual's  exposure  history  at  the  time  of  the  physical 
examination  was  very  beneficial.  i 

I 

The  industrial  hygienists  all  thought  that  communication  between  the 
industrial  hygienists  and  medical  care  providers  had  improved  because  physicians 
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were  asking  more  questions.  Generally,  the  medical  care  providers  felt  that 
communication  between  the  industrial  hygienists  and  medical  personnel  had  been 
maintained.  The  medical  care  providers  would  like  to  see  more  communication 
with  the  industrial  hygienists.  Four  out  of  five  of  the  industrial  hygienists 
felt  that  communcation  between  the  industrial  hygienists/safety  specialists  and 
the  work  center  supervisors  had  improved  since  the  advent  of  NOHIMS. 


Usefulness  of  NOHIMS  in  Monitoring  Medical  Surveillance 

This  section  contains  a  description  of  ways  that  NOHIMS  reports  would  aid 
in  the  monitoring  of  medical  surveillance.  Essentially  the  COSTAR  Report 
Generator  (CRG)  can  be  set  up  to  produce  various  reports  that  would  provide  data 
to  assist  in  determining  if  an  occupational  health  clinic  is  in  compliance  with 
medical  surveillance  program  requirements  and  to  help  assess  whether  there  has 
been  any  improvement  in  long-term  objectives/outcomes.  Since  the  CRG  was  not 
designed  for  the  purpose  of  monitoring  medical  care,  the  reports  will  only 
provide  raw  data  for  analysis.  If  ongoing  and  more  detailed  reports  are 
required  for  monitoring  medical  surveillance,  special  programming  to  extract  the 
appropriate  data  will  need  to  be  written  or  possibly  the  Medical  Query  Language 
could  be  integrated  with  NOHIMS  to  enhance  data  retrieval  mechanisms. 

NOHIMS  is  designed  to  identify  workers  who  require  an  annual  physical 
examination  and  to  provide  medical  care  providers  with  an  inventory  of  workers' 
exposures  and  medical  examination  requirements.  If  physical  examinations 
or  tests  yield  abnormal  findings  or  results,  follow-up  is  initiated.  To  monitor 
medical  surveillance,  these  requirements  could  be  translated  into  appropriate 
standards  to  be  verified  by  utilization  reports.  The  following  paragraphs 
describe  examples  of  such  CRG  reports. 

A  CRG  report  in  NOHIMS  called  List  of  Examined  lists  the  names,  social 
security  numbers,  dates  of  encounters,  dates  of  birth,  and  types  of  visit  for 
all  people  examined  during  a  specified  time  period.  The  list  of  workers 
requiring  examinations  for  a  given  month  produced  by  the  Hazard 
Exposure/Examination  Report  suboption  of  the  industrial  component  [the 
Individual  Exposure  Examination  Report  (IEER)]  could  be  compared  to  the  List  of 
Examined  report  to  determine  the  percentage  of  people  requiring  examinations  who 
actually  received  the  examination  and  within  what  time  period  they  received  the 
examination . 

Another  CRG  report  in  NOHIMS,  Lab  &  Pe,  selects  encounters  for  patients  who 
have  had  a  periodic  examination  and  lists  the  names,  dates  of  visit,  laboratory 
tests  ordered,  and  physical  examinations  performed  at  the  encounters.  To 
determine  if  individual  medical  surveillance  requirements  are  being  met,  the 
examination  and  test  recommendations  produced  in  the  IEER  could  be  compared  to 
those  services  actually  provided.  The  percentage  of  workers  requiring  a 
particular  test/procedure  who  had  the  test/procedure  performed  may  then  be 
calculated.  Variations  from  acceptable  levels  of  compliance  would  identify 
areas  of  care  requiring  investigation. 

A  series  of  reports  called  Had  PFT,  Had  SMAC,  and  Had  Audiogram  are 
examples  of  reports  that  could  be  used  to  determine  the  percentage  of  people 
receiving  a  particular  test/procedure  who  required  the  test/procedure .  Patients 
are  selected  for  the  report  if  they  had  the  particular  test  during  a  periodic 


201 


examination.  The  CRG  reports  list  the  names,  dates  of  visit,  results  of  tests, 
and  physical  examinations  performed.  When  compared  to  the  IEER,  the  percentage 
of  patients  receiving  a  particular  test/procedure  who  required  the  particular 
test/procedure  according  to  NOHIMS  can  be  determined.  Again,  variances  from 
acceptable  standards  may  flag  potential  compliance  problems.  However, 
investigations  of  this  standard  would  need  to  take  into  account  the  reasons  for 
performing  the  test/procedure  when  it  was  not  indicated  by  NOHIMS. 

Analysis  of  follow-up  procedures  is  a  fourth  area  in  which  NOHIMS  could  be 
used  for  monitoring  medical  surveillance.  For  example,  the  CRG  reports  Abnormal 
Glucose  and  Abnormal  Diff  select  patients  if  the  status  of  a  Blood  Glucose  or  of 
a  Differential  test  has  been  set  to  Abnormal  because  of  the  test  results  that 
were  entered.  These  reports  list  the  names,  dates  of  visit,  dates  of  last 
visit,  and  results  of  the  abnormal  test  for  patients  who  had  an  abnormal  test. 
When  compared  to  a  list  of  patients  examined  for  a  given  time  period  and  to  the 
last  visit  date,  the  percentage  of  patients  with  an  abnormal  test  result  who  had 
a  follow-up  visit  could  be  calculated.  Variances  from  acceptable  percentages 
could  be  investigated  to  determine  if  appropriate  follow-up  procedures  are  being 
used . 


Once  the  two  databases  have  been  built  up  over  an  extended  period  of  time, 
CRG  reports  could  also  be  used  to  measure  improvement  in  patient-specific 
ob jectives/outcomes  such  as  months  from  initial  base-line  examination  to 
identification  of  an  abnormal  diagnos(es)  or  an  abnormal  finding(s). 


Summary 

Some  ways  in  which  NOHIMS  could  aid  in  monitoring  medical  surveillance  were 
identified.  The  COSTAR  Report  Generator  (CRG)  contains  several  sample  reports 
that  could  be  used  to  determine  utilization  measures  such  as  the  percentage  of 
people  requiring  annual  examinations  who  received  the  examination,  the 
percentage  of  workers  requiring  a  particular  test/procedure  who  had  the 
test/procedure  performed,  the  percentage  of  people  receiving  a  particular 
test/procedure  who  required  the  test/procedure,  and  the  percentage  of  patients 
with  an  abnormal  test  result  who  had  a  follow-up  visit.  Eventually  CRG  reports 
could  be  used  to  assist  in  determining  improvement  in  patient-specific  long-term 
objectives/outcomes  such  as  earlier  identification  of  disease  or  abnormal 
findings.  The  CRG  reports  generally  will  only  provide  raw  data  for  utilization 
assessments.  If  more  sophisticated  procedures  or  measures  than  those  discussed 
above  are  required,  special  programming  will  be  required. 


EVALUATION  OF  USEFULNESS  OF  NOHIMS  DATABASE  FOR  LEGAL  EVIDENCE 

To  assess  the  usefulness  of  NOHIMS  as  a  database  for  legal  evidence  in  Navy 
proceedings,  we  reviewed  relevant  literature  and  conducted  in-person  interviews 
with  two  people  from  the  Safety  Office  of  the  Naval  Air  Rework  Facility  (NARF), 
San  Diego;  two  people  from  the  Production  Department  of  the  NARF,  San  Diego;  one 
person  from  the  Injury  Compensation  Program  for  the  Naval  Air  Station  and  the 
NARF,  San  Diego;  and  two  people  from  the  Civilian  Personnel  Office  of  the  Naval 
Hospital,  San  Diego.  The  four  people  from  the  NARF  were  interviewed  as  one 
group,  as  were  the  two  people  from  the  Naval  Hospital.  We  also  contacted 
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Navy  legal  counsel  by  telephone  at  the  Naval  Legal  Services  Office,  Naval 
Station,  San  Diego;  the  Labor  Relations  and  Litigation  Branch,  Naval  Air 
Station,  North  Island,  San  Diego;  and  the  Office  of  Counsel,  Naval  Air  Rework 
Facility,  Alameda,  California  to  discuss  the  role  of  NOHIMS  in  tort  claims 
against  the  Navy.  The  following  presents  our  findings  with  regard  to  the 
current  status  of  computer-stored  records  as  legal  evidence;  an  identification 
of  potential  uses  of  NOHIMS  data  for  legal  purposes,  the  types  of  data  required, 
and  the  effect  of  NOHIMS  on  claims;  and  an  analysis  of  the  NOHIMS  design  in 
light  of  the  requirements  identified. 


Current  Status  of  Computer-Stored  Records  As  Legal  Evidence 

During  the  first  phase  of  the  test  and  evaluation  of  NOHIMS,  we  conducted 
an  extensive  review  of  literature  relevant  to  occupational  health  information 
systems  and  system  evaluation  methodology.  Our  search  revealed  only  one  journal 
article  that  addressed  the  appropriateness  of  computer-stored  records  as  legal 
evidence. 

The  first  issue  that  was  addressed  in  this  article  was  compliance  with 
discovery  and  subpoenas  (Watson,  1983).  The  author  also  discussed  the 
introduction  of  computer  printouts  as  evidence.  A  third  issue  concerned 
judicial  acceptance  of  sampling  of  computer  records. 

The  author  concluded  that  computerized  records  are  now  treated  as  similar 
to,  if  not  identical  with,  more  traditional  records  for  purposes  of  discovery 
and  subpoena.  Although  a  discovering  party  may  be  required  to  develop  and 
utilize  its  own  program  to  access  a  particular  subset  of  data,  cooperation  on 
the  part  of  the  records'  custodian  is  clearly  appropriate  when  the  discovery  has 
been  judicially  compelled  or  agreed  to  by  the  parties.  The  records'  custodian 
may  be  required  to  translate  the  data  into  usable  form  (such  as  a  printout)  when 
discovery  would  be  impossible  otherwise.  The  records'  custodian,  on  the  other 
hand,  may  be  protected  by  the  courts  from  undue  burden  and  expense  by 
restricting  discovery  and/or  by  allocating  costs.  Precedence  in  court  cases  has 
established  that  Rule  26(b)(3)  of  the  Federal  Rules  of  Civil  Procedure  applies 
to  computer  programs  and  files  in  that  materials  prepared  in  anticipation  of 
litigation  or  for  trial  by  another  party  or  the  party's  representative  are 
protected . 


With  regard  to  the  introduction  of  computer  printouts  as  evidence  in 
administrative  or  judicial  proceedings,  the  acceptability  of  these  printouts 
depends  upon  an  adequate  foundation  regarding  both  the  process  of  recording  the 
data  at  issue  and  the  software  utilized  to  select  the  records.  Support  for  or 
challenge  to  this  foundation  will  probably  form  the  core  of  any  controversy  over 
the  admission  of  computer-generated  records.  Computer  printouts  may  be  admitted 
as  evidence  in  court  via  the  business  records  exception  to  the  hearsay  doctrine. 
In  order  for  documents  to  be  admitted  under  this  exception,  it  must  be  shown 
that  the  records  were  made  in  the  ordinary  course  of  business.  This  is  proved 
by  showing  that  it  is  part  of  regular  business  to  make  these  records  and  that 
they  were  made  within  a  reasonable  period  of  time  alter  the  act  (data  collection 
in  this  case).  An  adequate  legal  foundation  must  be  laid  before  these'  records 
may  be  introduced.  Generally,  witness(es)  with  relevant  educational  and 
occupational  backgrounds  who  are  familiar  with  the  computer  system,  the 
procedure  for  entering  the  information,  and  the  physical  plant  of  the  computer 


must  testify  regarding  these  matters.  The  representative( s)  must  also  describe 
the  security  precautions  taken  at  the  location  of  the  computer  to  restrict 
access  and  to  protect  the  information  in  the  database. 


The  author's  discussion  of  the  judicial  acceptance  of  computer  records 
sampling  concerned  sampling  data  used  to  determine  reimbursement  inaccuracies. 
The  projection  of  the  nature  of  a  large  population  through  the  review  of  a 
relatively  small  number  of  its  components  has  been  recognized  as  a  valid 
technique  and  approved  by  Federal  courts  in  a  number  of  cases  involving  the 
Social  Security  Act.  The  author  feels  that  this  sampling  and  projection 
technique  will  receive  more  widespread  application  in  the  future,  particularly 
in  the  area  of  quality  of  care  review. 

Legal  counsel  at  the  Office  of  Counsel,  Naval  Air  Rework  Facility,  Alameda, 
California  concurred  with  this  author's  opinion  that  computer-stored  records  are 
generally  acceptable  as  legal  evidence  in  court  proceedings. 


Potential  Legal  Uses  and  Effect  of  NOHIMS  Data 

The  seven  people  we  interviewed  identified  four  possible  legal  uses  for 
NOHIMS  data.  All  of  the  respondents  mentioned  that  NOHIMS  data  would  be  useful 
for  workmans'  compensation  claims.  They  felt  that  NOHIMS  would  be  useful  for 
claims  for  an  injury-specific  incident  such  as  a  traumatic  injury  or  spill,  as 
well  as  claims  as  a  result  of  long-term  occupational  exposure.  The  NARF 
personnel  and  the  respondents  from  the  Naval  Hospital,  San  Diego  both  mentioned 
that  NOHIMS  would  be  useful  in  responding  to  subpoenas  of  Navy  records.  A  few 
months  prior  to  our  interviews,  the  NARF  had  been  subpoenaed  with  regard  to  an 
asbestos  claim.  Both  groups  conceded,  however,  that  subpoenas  are  not  common. 
The  NARF  personnel  also  felt  that  NOHIMS  data  would  be  useful  in  continuation  of 
pay  determinations.  The  San  Diego  Naval  Hospital  people  thought  that  Veteran's 
Administration  disability  proceedings  might  be  another  legal  use  for  NOHIMS 
data.  None  of  the  people  we  interviewed  in  person  could  comment  on  whether 
NOHIMS  data  would  be  useful  for  tort  claims  actions  against  the  Navy.  We 
contacted  several  Navy  legal  offices  to  determine  if  NOHIMS  would  be  useful  in 
these  types  of  claims.  We  were  told  that  while  tort  claims  for  occupational 
injuries  or  diseases  were  rare,  data  on  historical  workplace  assignments  and 
hazardous  exposures  would  be  useful  in  litigating  these  claims. 

Eight  types  of  NOHIMS  data  were  identified  as  being  useful  for  legal 
purposes.  These  included  data  on  engineering  controls,  data  on  protection  used 
at  the  worksites,  hazardous  exposure  data,  physical  examination  data,  job 
history  data  (including  work  locations),  medical  history  data,  demographic  data, 
and  i  1  Iness/in jury  data.  The  head  of  the  Injury  Compensnt  ion  Program  pointed 
out  that  three-quarters  of  the  claims  he  sees  are  because  of  prolonged  and/or 
excessive  exposure  to  noise.  He  wanted  to  know  whether  he  would  be  able  to 
obtain  accurate  historical  data  on  exposures  from  NOHIMS.  NOHIMS  data  will  not 
be  useful  to  him  until  there  are  10- 11  years  of  data  since  today's  claims 
concern  exposures  that  occurred  10-11  years  ago.  Legal  counsel  agreed  that 
NOHIMS  data  would  not  be  particularly  useful  until  an  historical  database  of  at 
least  five  years  was  built.  The  head  of  the  Injury  Compensation  Program  also 
felt  that  illness  and  injury  data  would  be  very  important  for  claims.  The  NARF 
personnel  were  concerned  about  the  accuracy  of  the  work  records  of  the  workers, 
and  the  environment  and  work  location  definitions  in  NOHIMS.  They  were  keenly 
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aware  of  the  inaccuracies  in  the  NARF  Personnel  Extract  File  tape  used  by  N0H1MS 
to  update  workplace  assignments.  These  inaccuracies  lead  to  inaccuracies  in 
NOHIMS  workplace  assignments.  They  also  noted  that  environment  and  work 
location  definitions  in  NOHIMS  were  not  as  specific  as  is  often  required. 

Both  the  NARF  personnel  and  the  head  of  the  Injury  Compensation  Program 
believe  that  NOHIMS  will  not  alter  the  number  of  legal  claims  made  against  the 
Navy.  The  NARF  personnel  felt,  however,  that  they  will  be  able  to  respond  to 
claims  better  with  NOHIMS.  Down  the  road,  when  the  database  is  larger,  they 
feel  that  NOHIMS  will  help  management  defend  against  claims.  The  head  of  the 
Injury  Compensation  Program  thought  that  NOHIMS  could  speed  up  the  claims 
process  and  result  in  better  claims  determinations.  The  people  at  the  San  Diego 
Naval  Hospital  did  not  comment  on  the  effect  of  NOHIMS  on  the  number  of  legal 
claims. 


Analysis  of  NOHIMS  Design  for  Legal  Uses 

The  preceding  discussion  of  the  usefulness  of  the  NOHIMS  database  in  legal 
proceedings  raises  three  issues  related  to  the  NOHIMS  design.  To  be  useful  as 
legal  evidence  or  in  the  adjudication  of  claims,  NOHIMS  muse  gather  the  proper 
categories  of  data,  these  data  must  be  reliable,  and  they  must  be  retrievable  as 
needed.  The  following  subsections  evaluate  the  NOHIMS  design  in  light  of  these 
three  issues. 


Proper  Categories  of  Data 

The  industrial  component  of  NOHIMS  provides  the  capabilities  necessary  to 
enter,  store,  edit,  retrieve,  and  display  various  workplace  monitoring  data, 
including  work  history  data,  data  on  exposure  episodes,  environmental  monitoring 
and  industrial  hygiene  data  such  as  engineering  controls  and  protective 
equipment  used,  and  worker  demographic  data.  The  medical  component  of  NOHIMS 
provides  functions  for  entering,  storing,  editing,  retrieving,  and  displaying 
occupational  health  data,  including  data  from  preplacement/employment  physical 
examinations,  medical  surveillance  examinations,  job  certification  examinations, 
fitness  for  duty  and  return  to  work  interactions,  audiometric  data,  biomedical 
monitoring  data,  and  basic  medical  and  demographic  data.  It  does  not  have 
capabilities  for  entering  illness  and  injury  care  data.  However,  the  Naval 
Health  Research  Center  is  currently  developing  data  collection  forms  and  making 
changes  to  the  COSTAR  directory  to  allow  illness  and  injury  care  data  to  be 
processed  by  NOHIMS.  Data  collection  forms  for  both  occupational  histories  and 
medical  histories  were  designed  for  the  Occupational  Health  Unit,  North  Island. 
Initial  testing  showed  that  they  were  too  lengthy,  and  they  are  not  in  current 
use.  Consequenly,  NOHIMS  does  not  contain  occupational  and  medical  history  data 
yet . 


Reliability  of  NOHIMS  Data 

The  reliability  of  NOHIMS  data  is  dependent  on  both  internal  design 
features  and  external  site-dependent  implementation  features.  Internal  design 
features  include  NOHIMS'  general  reliability,  internal  data  integrity  features, 
and  logical  security  protection  features.  External  implementation  features 
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include  back-up  procedures,  physical  security  features,  and  quality  assurance 
measures  for  data  collection  and  data  entry. 

General  Reliability.  NOHIMS  is  considered  to  be  a  very  reliable  system  at 
this  point.  No  changes  were  made  to  the  data  storage  or  retrieval  functions  of 
public  domain  COSTAR  (the  basis  for  the  medical  component  of  NOHIMS).  Thus,  the 
medical  component  of  NOHIMS  is  based  on  a  software  package  that  has  been 
extensively  tested  in  the  field  for  the  past  ten  years.  The  only  bug  in  data 
retrieval  functions  that  the  contracted  NOHIMS  developers  are  aware  of  is  in  the 
COSTAR  Report  Generator  when  more  than  one  encounter  is  entered  for  a  patient  on 
a  given  day.  The  COSTAR  Report  Generator  does  not  differentiate  which  encounter 
the  data  for  that  date  are  associated  with  and  may  tally  data  items  multiple 
times  if  certain  precautions  are  not  taken.  This  problem  in  public  domain 
COSTAR  has  been  documented  by  the  contracted  developers  for  the  Naval  Health 
Research  Center  (NHRC).  The  industrial  component  of  NOHIMS  has  been  field 
tested  for  three  years  and  all  of  the  known  bugs  in  data  retrieval  and  storage 
processes  have  been  worked  out. 

Internal  Data  Integrity  Features.  Both  the  medical  and  industrial 
components  of  NOHIMS  have  system  functions  that  aid  in  restoring  the  database 
should  an  error  occur  or  if  the  system  crashes.  If  a  "hard"  computer  crash 
occurs  during  a  filing  operation,  the  global  files  may  be  corrupted.  The 
industrial  component  has  internal  integrity  check  operations  that  search  the 
global  files  and  record  any  erroneous  filing  conditions  that  are  found. 

Usually,  the  condition  can  be  corrected  through  execution  of  an  automatic 
correction  process.  This  process  is  capable  of  both  interpreting  the  error 
records  that  the  integrity  checking  routines  recorded  and  performing  the 
necessary  corrections  to  the  files. 

The  medical  component  of  NOHIMS  does  not  have  internal  integrity  check 
functions  in  case  of  a  hard  crash.  Instead,  the  system  relies  on  operating 
system  utilities  to  identify  and  repair  system  level  errors  (such  as  physical 
disk  structure  pointers)  and  on  a  manual  review  of  the  error  log  to  identify 
filing  sequence  errors.  If  filing  sequence  errors  have  occurred,  these  will 
require  either  programming  intervention  or  re-entry  of  data.  The  medical 
component  also  logs  "soft"  errors  that  occur  during  filing  with  system  messages 
to  help  detect  corrupted  patient  records  or  flag  potential  filing  problems. 

The  general  user  cannot  intentionally  or  unintentionally  corrupt  the  NOHIMS 
databases.  The  general  user  has  no  access  to  cross  references,  pointers,  or 
data  files.  Extensive  error  and  interrupt  trapping  prevents  the  user  from 
gaining  access  to  the  operating  system.  The  system  manager  or  someone  who 
enters  the  system  via  the  programmer's  access  code  could  potentially  corrupt  the 
databases,  so  these  people  must  take  great  care  when  working  in  the  system. 

NOHIMS  has  some  anticipation  of  the  type  of  input  to  be  expected  for  most 
data  fields  to  minimize  data  entry  errors.  Validity  of  the  input  is  checked 
either  through  pattern  matching  or  by  whether  a  data  item  (such  as  a  code, 
variable  name,  or  patient  name)  already  exists  in  the  system.  If  the  data  item 
does  not  exist  in  the  system,  NOHIMS  will  produce  a  list  of  choices  that  closely 
approximates  the  input  received. 

Logical  Security  Features.  The  logical  security  features  of  NOHIMS  that 
ensure  the  integrity  of  the  database  include  sign-on/off  procedures;  concealed 
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identification  codes;  limitations  on  access  to  functions  by  passwords,  by 
device,  and  by  class  of  user/identification  code  of  the  user;  interplay  of 
access  limitations  by  device  and  by  class  of  user/identification  code  of  the 
user;  time-outs  at  system  prompts;  interrupt  traps;  and  error  traps. 

Each  user  of  NOHIMS  is  assigned  an  identification  code  of  from  three  to 
five  characters  that  is  used  to  access  NOHIMS.  During  the  log-on  procedure,  the 
display  or  printout  of  the  identification  code  is  concealed  to  preserve  the 
integrity  of  the  log-on  codes.  Password  protection  may  be  applied  to  any  of  the 
modules  in  the  medical  component  to  restrict  unwarranted  access  to  the  medical 
database. 

Both  the  industrial  and  medical  components  have  a  security  feature  that 
limits  access  to  modules  and/or  options  depending  on  the  device  that  is  being 
used  to  access  the  system.  Thus,  access  at  a  given  terminal  or  printer  can  be 
limited  to  any  combination  of  modules  and/or  options.  The  medical  component 
also  allows  the  restriction  of  access  to  NOHIMS  options  by  class  of  user.  The 
industrial  component,  on  the  other  hand,  also  allows  the  system  manager  to  limit 
access  to  system  options  by  the  identification  code  of  the  user.  The  access 
limitations  by  device  and  by  class  of  user/identification  code  of  the  user 
interact  in  NOHIMS  to  further  restrict  access.  The  access  specifications  for  a 
given  user  and  the  device  currently  being  used  are  combined  to  determine  the 
modules  and/or  options  that  may  be  accessed  by  that  user  using  that  device. 

Only  those  modules  and/or  options  that  are  allowed  for  both  the  user  and  the 
device  will  be  accessible.  These  three  functions  are  useful  for  preventing 
unauthorized  access  to  critical  functions  or  sensitive  data  in  NOHIMS. 

Certain  options  in  the  NOHIMS  medical  component  have  an  interrupt  trap  that 
will  return  the  user  to  the  system  option  menu  if  the  function  is  interrupted. 
This  security  feature  prevents  the  user  from  falling  out  of  NOHIMS  into  the 
operating  system.  None  of  the  processes  in  the  industrial  component  may  be 
interrupted  so  this  feature  is  not  required  in  the  industrial  component.  Both 
the  industrial  and  medical  components  have  extensive  error  trapping  mechanisms. 
If  a  program  error  occurs,  the  error  is  recorded  in  one  of  the  NOHIMS  error  logs 
and  the  user  is  returned  to  a  system  option  menu.  These  traps  prevent 
inadvertent  access  to  the  operating  system.  Time-outs  at  system  prompts  also 
help  to  prevent  unauthorized  access  to  NOHIMS  by  disconnecting  a  device  from 
NOHIMS  if  the  device  is  left  unattended  for  an  extended  period  of  time. 

Back-Up  Procedures.  To  ensure  the  reliability  of  NOHIMS  data,  adequate 
back-up  procedures  must  be  utilized  at  the  application  site.  It  is  recommended 
that  the  entire  NOHIMS  system  be  backed  up  on  another  disk  at  least  daily. 

Another  periodic  back-up  copy  should  be  kept  off-site.  If  the  hard  disk  copies 
are  adequately  checked  for  integrity,  they  will  provide  necessary  back-up  for 
the  system.  In  the  event  of  a  data  crash,  a  disk  back-up  can  be  restored 
easily.  At  most,  data  input  since  the  last  back-up  was  made  would  need  to  be 
re-entered.  Since  virtually  all  data  entered  into  NOHIMS  are  entered  from  hard 
copy,  it  is  relatively  easy  to  keep  an  audit  trail  of  data  entry.  The  operating 
systems  that  support  MUMPS  all  support  these  standard  back-up  functions. 

NOHIMS  records  may  be  downloaded  to  magnetic  tape  for  record  archiving.  It 
should  be  noted,  however,  that  magnetic  tape  is  not  considered  to  be  a  secure 
medium.  A  more  appropriate  legal  medium  for  storage  of  downloaded  records  would 
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be  hardcopy  on  paper.  Paper  records  could  then  be  microfiched  for  easier 
storage  and  multiple  copies  of  the  microfiches  made. 

Physical  Security  Features.  Adequate  physical  security  must  be  in  force  to 
protect  the  integrity  of  the  NOHIMS  database.  Cipher  locks  on  doors  and  log 
books  for  people  entering  the  computer  room  are  two  ways  to  physically  restrict 
access  to  NOHIMS.  The  computer  room  at  the  Naval  Health  Research  Center  (where 
the  mainframe  PDP  11/24  on  which  NOHIMS  resides  for  the  San  Diego  test  site  is 
located)  has  cipher  locks.  NHRC  does  not  keep  a  log  book  of  noncomputer 
personnel  entering  the  room  nor  do  the  rooms  that  contain  terminals  and  printers 
connected  to  the  PDP  have  cipher  locks.  At  the  North  Island  test  site,  neither 
the  Occupational  Health  Unit  nor  the  Industrial  Hygiene  Division  rooms  that 
contain  the  terminals  and  printers  have  cipher  locks.  At  Bremerton,  the  door  to 
the  room  that  contains  the  Plessey  mainframe  has  cipher  locks.  There  is  no  log 
book  for  people  entering  this  computer  room. 

Quality  Assurance  Measures  for  Data  Collection  and  Data  Entry.  The 
accuracy  of  the  NOHIMS  database  relies  in  part  on  the  accuracy  of  data  input  to 
the  system.  Adequate  measures  must  be  taken  to  ensure  that  data  collection  and 
data  entry  personnel  have  been  properly  trained  in  correct  procedures.  While 
NOHIMS  can  check  the  validity  of  data  input  to  a  degree,  some  form  of  data 
collection  and  entry  verification  should  be  used.  Possible  methods  range  from 
full  100  percent  verification  of  data  collection  and  data  entry,  to  sequential 
sampling  of  data  collection  and  entry  (e.g.,  100  percent  verification  of  every 
Nth  encounter/survey ) ,  to  full  or  sequential  verification  of  selected  critical 
data  items,  to  spot-checking,  or  to  verification  during  training  periods  only. 

Issues  regarding  inaccurate  sources  of  data  must  be  dealt  with  quickly  and 
appropriately  to  preserve  the  integrity  of  the  NOHIMS  database.  Since  accurate 
work  histories  are  so  essential  to  NOHIMS  functions,  the  problems  with  the 
Personnel  Extract  File  need  to  be  resolved. 

To  meet  the  criteria  for  admission  of  computer-stored  records  as  legal 
evidence,  data  entry  to  NOHIMS  must  be  completed  within  a  reasonable  period  of 
time  from  data  collection.  Therefore,  adequate  personnel  must  be  provided  for 
timely  entry  of  NOHIMS  data. 


Retrievability  of  NOHIMS  Data 

There  are  eight  functions  in  the  industrial  component  of  NOHIMS  that  will 
retrieve  data  from  the  industrial  database.  These  are  the  display  functions  of 
the  five  data  modules — Display  Organization ,  Display  Personnel  Data,  Display 
Environment  Users,  Review  Environment  Information,  Display  Survey  Data,  and 
Display  Hazard  Data;  the  Hazard  Exposure/Examination  Report  option  in  the 
Personnel  Data  module;  and  the  Query/Report  module.  The  display  options  of  the 
five  data  modules  can  retrieve  and  display  information  both  specific  to  the  data 
module  (e.g.,  agent  names  and  exposure  limits)  and  from  relationships  between 
the  modules  (e.g.,  environments  that  contain  a  particular  agent).  The  Hazard 
Exposure/Examination  Report  option  produces  the  hazard  exposure  summary  and 
medical  examination  requirement  reports  for  selected  workers.  The  Query/Report 
module  provides  an  ad  hoc  information  retrieval  and  display  capability  that 
extends  to  almost  every  data  item  in  the  industrial  component.  Retrieval  of 
data  in  the  industrial  component  is  limited  to  current  data  such  as  current 
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exposures  and  workplace  assignments.  Historical  data  for  many  variables  are 
retained  in  the  industrial  component  files,  although  at  present  these  data 
cannot  be  retrieved.  Based  on  the  discussions  with  the  interviewees,  access  to 
historical  NOHIMS  data  is  essential  for  responding  to  claims.  NOHIMS  will 
require  augmentation  in  order  to  be  useful  in  the  adjudication  of  claims. 

Four  modules  are  used  to  retrieve  data  in  the  medical  component  of  NOHIMS. 
These  are  the  Registration  module,  the  Display  Medical  Data  module,  the  Print 
Medical  Data  module,  and  the  COSTAR  Report  Generator.  The  Display  Registration 
option  in  the  Registration  module  and  the  Registration  Data  Check  option  in  the 
Display  Medical  Data  module  are  used  to  retrieve  registration  data.  Three  of 
the  options  in  the  Display  Medical  Data  module  retrieve  information  about 
individual  encounters;  five  other  options  summarize  data  across  encounters.  The 
Print  Medical  Data  options  print  hardcopies  of  Encounter  Reports,  Registration 
Data  Checks,  Status  Reports,  and/or  Flowcharts  for  particular  groups  of 
individuals.  The  COSTAR  Report  Generator  options  cover  three  different 
functions.  These  are  the  actual  COSTAR  Report  Generator,  the  Medical  Query 
Language,  and  a  function  that  retrieves  and  reformats  certain  data  for  research 
purposes.  The  COSTAR  Report  Generator  produces  listings  and  cross  tabulations 
according  to  user-defined  criteria.  The  Medical  Query  Language  is  a  more 
powerful  data  retrieval  language  that  is  under  examination  as  a  future 
enhancement  for  NOHIMS.  Five  options  in  the  COSTAR  Report  Generator  module 
produce  a  fixed-length,  fixed-format  record  from  COSTAR  data  for  use  in  research 
functions . 

Presently,  there  are  only  two  links  between  the  two  components  of  NOHIMS  in 
data  display  or  retrieval  functions.  These  are  the  display  of  current  exposure 
data  in  the  Patient  Summary  and  the  function  in  the  COSTAR  Report  Generator 
module  that  produces  the  fixed-length,  fixed-format  records.  The  patients  that 
are  identified  for  retrieval  by  this  function  may  be  selected  using  criteria 
from  the  industrial  component.  It  is  not  clear  that  any  links  between  the  data 
in  the  two  components  are  required  for  legal  purposes,  but  if  it  is  determined 
that  links  are  required,  the  retrieval  functions  for  NOHIMS  will  need  to  be 
modified  accordingly. 


Summary 

A  review  of  relevant  literature  revealed  one  journal  article  about  the  use 
of  computer-stored  data  for  legal  evidence.  The  author  concluded  that  it  is 
appropriate  for  computer  records'  custodians  to  respond  to  subpoena  requests  for 
data.  Computer-stored  records  and  printouts  will  be  acceptable  as  legal 
evidence  provided  the  records  have  been  made  in  the  normal  course  of  business 
and  a  firm  legal  foundation  for  the  validity  of  the  data  is  established.  The 
use  of  a  sample  of  records  to  project  to  the  larger  population  is  an  acceptable 
technique  and  will  probably  be  used  more  in  the  future. 

Interviews  with  personnel  from  the  Naval  Air  Rework  Facility  (NARF),  North 
Island;  the  Naval  Hospital,  San  Diego;  and  the  Injury  Compensation  Program  for 
the  Naval  Air  Station/NARF,  North  Island  revealed  several  potential  uses  for 
NOHIMS  data.  NOHIMS  will  probably  be  useful  in  workmans'  compensation  claims 
and  responses  to  subpoenas,  and  possibly  useful  in  continuation  of  pay 
determinations  and  Veterans'  Administration  disability  proceedings.  NOHIMS  data 


will  not  be  used  much  for  tort  claims  actions  because  tort  claims  in  the  area  of 
occupational  health  are  rare. 

Eight  types  of  data  were  identified  as  being  useful  for  legal  purposes. 
These  were  data  on  engineering  controls,  data  on  protective  equipment  used  at 
worksites,  hazardous  exposure  data,  physical  examination  data,  job  history  data, 
medical  history  data,  demographic  data,  and  il lness/in jury  data.  The 
interviewees  pointed  out,  however,  that  NOHIMS  would  not  really  be  useful  until 
an  historical  database  is  built.  The  interviewees  had  concerns  regarding  the 
accuracy  of  the  work  history  data  and  whether  historical  exposure  data  would  be 
obtainable.  Inaccuracies  in  the  Personnel  Extract  File  that  feeds  data  to 
NOHIMS  need  to  be  corrected  and  capabilities  for  retrieval  of  historical 
exposure  data  need  to  be  added  to  NOHIMS  in  order  to  make  the  NOHIMS  database 
useful  for  legal  purposes.  The  respondents  did  not  believe  that  NOHIMS  would 
effect  the  number  of  claims  made  against  the  Navy;  however,  there  was  general 
agreement  that  NOHIMS  would  help  management  to  respond  to  claims  in  the  future. 

The  NOHIMS  design  was  analyzed  in  light  of  the  issues  raised  in  the 
preceding  discussions.  To  be  useful  as  legal  evidence  in  the  adjudication  of 
claims,  NOHIMS  must  gather  the  proper  categories  of  data,  these  data  must  be 
reliable,  and  they  must  be  retrievable  as  needed. 

NOHIMS  enters,  stores,  retrieves,  and  displays  most  of  the  types  of  data 
required  for  legal  purposes.  NOHIMS  processes  data  on  engineering  controls, 
protective  equipment  used,  hazardous  exposures,  physical  examination  data,  and 
demographic  data.  At  present,  NOHIMS  does  not  process  illness/in jury  care  data. 
The  Naval  Health  Research  Center  is  currently  adding  this  capability  to  NOHIMS. 
Although  occupational  and  medical  history  forms  were  designed  for  NOHIMS, 
testing  revealed  that  they  were  too  lengthy  and,  thus,  these  two  types  of  data 
are  not  implemented  in  NOHIMS  yet. 

NOHIMS  has  a  variety  of  features  to  ensure  the  reliability  of  the  database. 
NOHIMS  has  been  field  tested  for  an  extended  period  of  time  and  has  proven  to  be 
very  reliable.  NOHIMS  has  internal  features  that  ensure  data  integrity  by 
detecting  error  conditions  and  aiding  in  data  recovery  if  the  system  crashes. 

The  industrial  component  has  internal  integrity  check  operations  that  can  detect 
and  correct  filing  errors.  Extensive  error  and  interrupt  trapping  prevents 
corruption  of  the  database  through  inadvertent  access  to  the  operating  system. 

NOHIMS  has  a  variety  of  logical  security  features  that  protect  the  database 
from  corruption.  These  include  limitations  on  access  to  certain  functions  by 
passwords,  by  device,  and  by  class  of  user/identification  code  of  the  user. 
NOHIMS  also  has  interplay  between  the  access  limitations  by  device  and  the 
access  limitations  by  class  of  user/identification  code  of  the  user.  It  has 
passwords  to  log-on,  time-outs  at  system  prompts,  concealed  identification 
codes,  and  error  traps  and  interrupt  traps  to  prevent  inadvertent  access  to  the 
operating  system. 

The  reliability  of  NOHIMS  also  depends  on  certain  external  implementation 
features  that  are  site-dependent.  Adequate  system  back-ups  must  be  made  on  an 
at  least  daily  basis.  If  records  are  archived,  a  secure  medium  such  as  paper 
and/or  microfiche  should  be  used  rather  than  magnetic  tape.  Adequate  physical 
features  must  be  in  force.  Possible  physical  security  measures  include  cipher 
locks  on  doors  and  log  books  for  people  entering  computer  rooms.  Appropriate 


quality  assurance  measures  for  data  collection  and  entry  must  be  devised  to 
maintain  accuracy  in  the  database.  Adequate  training  of  both  data  collection 
and  data  entry  personnel  must  be  provided.  Appropriate  verification  procedures 
for  both  data  collection  and  data  entry  must  be  devised  and  maintained. 

Features  that  allow  retrieval  of  historical  exposure  data  must  be  added  to 
NOHIMS.  If  links  between  medical  and  industrial  data  are  required, 
modifications  to  the  system  will  need  to  be  made. 


EVALUATION  OF  NOHIMS  AS  AN  AID  TO  EPIDEMIOLOGIC  RESEARCH 

We  asked  the  NOHIMS  developers  at  the  Naval  Health  Research  Center  (NHRC) 
to  evaluate  the  usefulness  of  NOHIMS  as  an  aid  to  epidemiologic  research.  We 
questioned  them  about  the  research  functions  for  which  NOHIMS  will  be  useful, 
the  kind  of  data  that  will  be  required  for  these  investigations,  the  features 
and/or  capabilities  of  NOHIMS  that  will  be  useful  and,  finally,  their  assessment 
of  the  adequacy  of  NOHIMS  for  epidemiologic  research.  A  sample  questionnaire 
guide  with  the  questions  we  used  may  be  found  in  Appendix  A,  Component  27. 

Table  64  shows  that  all  of  the  NHRC  NOHIMS  developers  thought  that  NOHIMS 
will  be  useful  for  the  functions  we  listed  in  the  questionnaire,  namely, 
identifying  populations  at  risk/cohorts;  identifying  workers  exposed,  exposure 
levels,  and  length  of  exposure;  determining  medical  effects  of  exposures; 
detecting  disease  trends  and  outbreaks;  and  identifying  common  risk  factors 
among  exposed  workers.  In  addition,  they  suggested  five  more  research  functions 
for  which  NOHIMS  will  be  useful.  These  included  identifying  new  risk  factors, 
which  was  mentioned  by  two  of  the  four  NOHIMS  developers;  investigating 
dose/response  relationships,  assessment  of  risk,  survival  analyses,  and  case- 
control  studies  which  were  each  mentioned  by  one  of  the  respondents. 

All  of  the  NHRC  NOHIMS  developers  agreed  that  the  NOHIMS  data  required  to 
conduct  these  epidemiologic  investigations  were  demographic  data,  exposure 
histories,  occupational  histories,  medical  histories,  and  physical  examination 
data.  Three  people  also  thought  that  mortality  data  are  necessary  (see 
Table  65).  Currently,  NOHIMS  does  not  collect  mortality  data,  but  it  could  be 
modified  to  do  so.  Exposure  data  are  stored  historically,  but  will  require 
special  programming  to  retrieve  them.  Data  collection  forms  were  designed  and 
directory  work  was  performed  to  gather  occupational  and  medical  history  data; 
however,  these  forms  have  not  been  operationally  implemented  as  yet.  Thus,  of 
the  data  that  are  required  for  epidemiologic  research,  only  demographic  data  and 
physical  examination  data  are  readily  available  at  present. 

When  we  asked  the  NHRC  NOHIMS  developers  to  identify  the  features  and 
capabilities  of  NOHIMS  that  will  be  useful  in  epidemiologic  research,  all  of  the 
developers  mentioned  NOHIMS'  cross-referencing  ability  (see  Table  66).  One  of 
these  developers  thought  that  the  potential  of  tying  together  medical  test  data 
and  exposure  data  was  especially  important.  Three  ol  the  four  developers 
interviewed  thought  that  the  reference  tables,  the  ability  to  analyze  data  at 
varying  levels,  and  the  ad  hoc  information  retrieval  capabilities  of  NOHIMS  will 
be  useful  in  epidemiologic  research.  Two  developers  specifically  mentioned  that 
having  data  on  an  entire  population  (i.e.,  both  the  sick  and  well,  exposed  and 
not  exposed)  will  be  very  useful. 


TABLE  64 

Research  Functions  NOHIMS  Will  Be  Useful  for 

According  to  NHRC  NOHIMS  Developers 
(Number  who  mentioned  function;  multiple  answers  allowed) 

TOTAL 

%  of  Total 
Interviewed 

Identifying  populations  at 
risk/ cohorts 

4 

100 

Identifying  workers  exposed, 
exposure  levels,  and  length 
of  exposure 

4 

100 

Determining  medical  effects 
of  exposures 

4 

100 

Detecting  disease  trends/ 
outbreaks 

4 

100 

Identifying  common  risk 
factors  among  exposed  workers 

4 

100 

Other: 

Identifying  new  risk 
factors 

2 

50 

Investigating  dose/ 
response  relationships 

1 

25 

Assessment  of  risk 

1 

25 

Survival  analyses 

1 

25 

Case-control  studies 

1 

25 

TOTAL  INTERVIEWED 
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TABLE  65 

Data  Required  for  Epidemiologic  Investigation 
According  to  NHRC  NOHIMS  Developers 
(Number  who  mentioned  data;  multiple  answers  allowed) 


TOTAL 

%  of  Total 
Interviewed 

Demographic  data 

4 

100 

Worker  exposure  histories 

4 

100 

Worker  occupational  histories 

4 

100 

Worker  medical  histories 

4 

100 

Physical  examination  data 

4 

100 

Mortality  data 

3 

75 

TOTAL  INTERVIEWED 

4 

100 

213 


TABLE  66 

Features/Capabilities  of  NOHIMS 
That  Will  Be  Useful  in  Epidemiologic  Research 
According  to  NHRC  NOHIMS  Developers 
(Number  who  mentioned  feature;  multiple  answers  allowed) 


%  of  Total 
TOTAL  Interviewed 


Cross-referencing  ability  4  100 
Reference  tables  3  75 
Ability  to  analyze  data  at  varying  levels 

(individual,  selected  groups,  or  population)  3  75 
Ad  hoc  information  retrieval  capabilities  3  75 
Other: 

Population  data  2  50 


TOTAL  INTERVIEWED 


4 


100 


Table  67  contains  the  NHRC  NOHIMS  developers'  overall  assessment  of  the 
adequacy  of  NOHIMS  for  conducting  epidemiologic  research.  Two  of  the  four  NHRC 
NOHIMS  developers  gave  NOHIMS  a  rating  of  very  adequate  for  conducting 
epidemiologic  research.  One  of  the  developers  gave  NOHIMS  a  rating  of  adequate. 
He  explained  that  this  rating  was  for  now,  but  he  felt  that  the  system  will 
become  very  adequate  in  time  as  NOHIMS  is  used  more.  One  developer  gave  NOHIMS 
a  rating  of  somewhat  adequate  because  he  was  concerned  about  the  ability  of 
NOHIMS  to  adequately  extract  data  for  research  purposes.  He  commented  that  the 
Medical  Query  Language,  a  powerful  MUMPS-based  data  retrieval  package  which  can 
be  linked  to  NOHIMS,  might  be  useful  for  achieving  this  end.  Several  of  the 
developers  mentioned  that  NOHIMS  needs  a  statistical  capability  in  order  to  be 
able  to  adequately  utilize  the  data.  One  developer  pointed  out  that  NOHIMS 
simply  provides  the  raw  data  for  research;  this  raw  data  will  still  need  to  be 
standardized  for  use  in  research  because  the  data  are  collected  for  occupational 
health  purposes  and  not  for  research. 


Summary 

The  NHRC  NOHIMS  developers  thought  that  NOHIMS  will  be  adequate  for 
conducting  epidemiologic  research,  provided  that  methodologies  for  retrieving 
the  data  in  a  standardized  format  and  that  appropriate  analytical  functions  are 
developed.  Medical  history  and  occupational  history  data  must  be  collected  in 
some  form.  They  felt  that  there  will  be  many  uses  for  NOHIMS  and  its  database 
in  epidemiologic  research.  The  main  functions  of  NOHIMS  will  be  to  provide 
demographic,  exposure  history,  occupational  history,  medical  history,  and 
physical  examination  data  for  use  in  a  variety  of  epidemiological  research 
investigations  such  as  case-control  and  prospective  studies.  With  data  from 
NOHIMS,  NHRC  and  other  Navy  entities  will  be  able  to  assess  and  identify  risk, 
perform  longitudinal  studies  on  the  medical  effects  of  exposures,  identify 
various  populations  and  cohorts,  study  disease  trends,  and  investigate  dose/ 
response  relationships.  The  developers  thought  that  NOHIMS'  inherent  cross- 
referencing  ability,  the  capability  of  analyzing  data  at  varying  levels,  the 
reference  tables,  and  the  ad  hoc  information  retrieval  capabilities  will  all  be 
useful  in  epidemiologic  research  investigations. 


ASSESSMENT  OF  USEFULNESS  OF  NOHIMS  IN  ADMINISTRATIVE  FUNCTIONS 

To  assess  the  usefulness  of  NOHIMS  in  administrative  functions,  we 
interviewed  four  NHRC  NOHIMS  developers,  five  higher  level  managers,  and  four 
test  site  administrators  using  Component  28  of  Appendix  A.  In  other  sections  we 
interviewed  seven  higher  level  managers.  However,  one  of  these  seven  managers 
was  interviewed  using  the  NEHC  Project  Management  Team  guide  and  one  of  the  1 

managers  at  Bremerton  was  inadvertently  interviewed  with  a  different  interview  I 

guide,  both  of  which  did  not  contain  Component  28.  This  section  reports  data 
for  four  rather  than  two  test  site  administrators — two  that  were  classified  as 
test  site  administrators  in  other  sections  of  the  evaluation  and  an  industrial 
hygienist  and  a  medical  care  provider  who  were  classified  as  system  users  in 
other  sections.  The  latter  two  people  have  administrative  roles  in  their 
divisions  and  so  we  felt  they  would  have  worthwhile  comments  on  the  usefulness  I 

of  NOHIMS  in  administrative  functions.  One  of  the  four  NHRC  NOHIMS  developers 
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TABLE  67 

Assessment  of  the  Adequacy  of  NOHIMS  for  Conducting  Epidemiologic  Research 

According  to  NHRC  NOHIMS  Developers 
(Number  who  mentioned  rating) 


TOTAL 


Very  adequate 
Adequate 

Somewhat  adequate 
Somewhat  inadequate 
Inadequate 
Very  inadequate 


TOTAL  INTERVIEWED 


%  of  Total 
Interviewed 


4 
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declined  to  comment  on  any  of  the  questions  in  this  section  of  the  interview 
because  he  was  not  familiar  with  NOHIMS'  administrative  functions. 

The  NHRC  NOHIMS  developers,  higher  level  managers,  and  test  site 
administrators  were  asked  to  identify  the  administrative  functions  for  which 
they  thought  NOHIMS  would  be  useful,  the  kinds  of  data  required  for  these 
functions,  and  the  features/capabilities  of  NOHIMS  that  will  be  useful  in 
administrative  functions.  The  higher  level  managers  and  test  site 
administrators  were  asked  to  rate  the  effect  NOHIMS  had  had  on  the  amount  of 
required  paperwork,  the  effect  of  NOHIMS  on  the  standardization  of  reports  and 
forms,  and  the  usefulness  of  having  timely  and  perpetual  access  to 
administrative  data. 


Table  68  presents  the  administrative  functions  for  which  the  interviewees 
thought  NOHIMS  would  be  of  use.  Every  one  of  the  respondents  thought  that 
NOHIMS  would  be  useful  in  increasing  the  standardization  of  data  collection 
forms  and  in  manpower/resource  planning.  However,  one  higher  level  manager  noted 
that  the  Navy  needs  to  devise  directives  to  establish  NOHIMS  forms  as  the 
standard.  Eleven  out  of  12  (92%)  of  the  respondents  mentioned  the  usefulness  of 
having  timely  and  perpetual  access  to  administrative  data.  Generating 
administrative  reports  and  increasing  standardization  of  reports  were  mentioned 
next  most  frequently  (mentioned  by  83%  of  the  respondents).  Five  other 
administrative  functions  for  which  NOHIMS  will  be  useful  were  mentioned  by  the 
respondents  but  to  a  lesser  degree.  These  included  reducing  paperwork  (67%), 
determining  environmental  pay  decisions  (58%),  managing  inspection  requirements 
(50%),  maintaining  equipment  lists  (50%),  and  time  and  motion  studies  (17%).  In 
addition,  an  NHRC  NOHIMS  developer  thought  that  NOHIMS  would  be  useful  as  a 
built-in  alarm  system  to  alert  administrators  to  real  or  potential  problem 
areas.  A  test  site  administrator  mentioned  the  usefulness  of  NOHIMS  in  planning 
and  conducting  follow-up  surveys.  In  another  part  of  his  interview,  the 
Bremerton  higher  level  manager  who  was  not  interviewed  with  this  section  on 
administrative  functions  reported  using  NOHIMS  for  producing  management  data  at 
least  monthly. 

The  question  of  whether  NOHIMS  was  useful  in  determining  environmental  pay 
decisions  revealed  an  obvious  source  of  controversy.  Three  higher  level 
managers  and  one  NHRC  NOHIMS  developer  felt  that  while  NOHIMS  could  provide  data 
for  these  decisions,  it  should  not  be  used  for  this  purpose.  Specific  comments 
by  these  four  respondents  included  "it  muddies  the  intent  of  NOHIMS  [to  use  the 
system  in  this  way],"  "would  like  to  see  [these  decisions]  totally  eliminated — 
[instead  we  should]  make  the  environment  safe,"  and  "practically  speaking  you 
could  use  NOHIMS  for  these  decisions,  but  people  should  not  be  in  the  hazardous 
environment  at  all." 

Table  69  shows  the  kinds  of  data  that  the  interviewees  identified  as  being 
useful  for  administrative  functions.  Of  the  two  kinds  of  data  we  listed  in  the 
questionnaire,  83  percent  of  those  who  responded  to  this  question  felt  that 
manpower/resource  utilization  data  were  required  for  administrative  functions 
and  67  percent  of  the  respondents  thought  that  service  utilization  data  were 
needed.  Eighty-three  percent  of  the  respondents  also  mentioned  needing  hazard 
exposure  data,  17  percent  mentioned  medical  monitoring  data,  and  one  person  (8%) 
mentioned  needing  acute  care  data. 
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TABLE  68 

Administrative  Functions  for  Which  NOHIMS  Will  Be  Useful 
(Number  who  mentioned  function;  multiple  answers  allowed) 


NHRC 

NOHIMS 


Higher 

Level 


Developers  Managers 


Test  Site 
Admin. 


TOTAL 


Increasing 

standardization  of 

data  collection  forms  3 

Manpower/ resource 
planning  3 

Timely  and 
perpetual  access  to 
administrative  data  3 

Generating 

administrative  reports  3 

Increasing 

standardization 

of  reports  3 

Reducing  paperwork  3 

Determining 

environmental 

pay  decisions  1 

Managing  inspection 
requirements  2 

Maintaining 

equipment  lists  1 

Time  and 

motion  studies  1 

Other:  Built-in  alarm 

system  1 

Follow-up  surveys  0 


TOTAL  WHO  ANSWERED 
No  Comment 


%  of 

Total  Who 
Answered 


TOTAL  INTERVIEWED 


TABLE  69 

Kinds  of  Data  Required  for  Administrative  Functions 
(Number  who  mentioned  kind  of  data;  multiple  answers  allowed) 


NHRC 

NOHIMS 

Developers 

Higher 

Level 

Managers 

Test  Site 
Admin. 

TOTAL 

%  of 

Total  Who 
Answered 

Manpower/ resource 
utilization  data 

2 

4 

4 

10 

83 

Service 

utilization  data 

1 

3 

4 

8 

67 

Other  data: 


Hazard  exposures  2  4  4  10  83 
Medical  monitoring  0  1  1  2  17 
Acute  care  0  0  118 


Table  70  shows  the  features/capabilities  of  NOHIMS  that  the  respondents 
felt  would  be  useful  in  administrative  functions.  All  of  the  respondents 
mentioned  that  the  on-line  look-up/Interactive  Query  function  in  the  industrial 
component  would  be  useful.  Eighty-three  percent  of  the  respondents  thought  that 
NOHIMS'  ad  hoc  report  generation  capabilities  would  be  useful,  and  75  percent 
thought  that  the  standard  report  generation  capabilities  would  be  of  use. 

The  respondents  would  like  some  additional  capabilities  to  make  NOHIMS  more 
useful  for  administrative  functions.  One  test  site  administrator  requested  the 
ability  to  test  values  of  data  items  (such  as  a  value  greater  than  X)  in  the 
Interactive  Query  process  and  the  ability  to  generate  narrative  reports  with  a 
word  processor  that  would  automatically  extract  survey  data  from  the  database. 
Another  test  site  administrator  would  like  to  be  able  to  generate  tables  and 
graphs  and  to  have  the  ability  to  determine  the  report  formats.  A  higher  level 
manager  would  like  a  spreadsheet  capability  and  an  overall  office  management 
module,  and  to  be  able  to  track  occupational  health  personnel  on  the  system. 

Two  other  higher  level  managers  stated  that  they  need  a  statistics  capability. 

The  respondents  varied  in  their  perception  of  how  NOHIMS  has  affected  the 
amount  of  required  paperwork  (see  Table  71).  The  varied  perceptions  in  the 
effect  of  NOHIMS  on  the  amount  of  paperwork  could  not  be  attributed  to  whether 
the  respondent  was  involved  with  the  medical  or  industrial  component  of  NOHIMS. 
The  higher  level  managers  were  more  divergent  in  their  ratings  than  the  test 
site  administrators.  Two  of  the  respondents  (25%)  gave  NOHIMS  a  rating  of 
having  greatly  increased  paperwork,  two  (25%)  gave  NOHIMS  a  rating  of  somewhat 
increased,  two  (25%)  gave  a  rating  of  no  effect,  and  two  (25%)  rated  NOHIMS  as 
somewhat  decreasing  the  amount  of  required  paperwork.  No  one  said  that  NOHIMS 
had  greatly  decreased  the  amount  of  required  paperwork,  although  one  higher 
level  manager  who  gave  NOHIMS  a  rating  of  somewhat  decreasing  paperwork  said 
that  NOHIMS  might  greatly  decrease  paperwork  in  the  future.  One  test  site 
administrator  who  had  said  that  NOHIMS  had  increased  the  amount  of  required 
paperwork  explained  that  this  was  because  "we  are  not  jotting  things  down  in  our 
minds  anymore."  One  manager  who  rated  NOHIMS  as  increasing  the  amount  of 
required  paperwork  commented  that  "[the  increase]  is  not  bad,  we  are  just 
collecting  more  data  that  may  help  someone."  Another  manager  thought  that  even 
if  NOHIMS  forms  are  accepted  as  the  standard,  there  will  be  a  slight  increase  in 
the  amount  of  paperwork  because  the  data  collection  forms  are  more 
Comprehensive.  He  also  felt  that  there  is  a  great  increase  in  paperwork  for 
now,  but  when  the  forms  are  printed  the  amount  of  paperwork  may  decrease. 

In  response  to  a  question  about  the  effect  of  NOHIMS  on  the  standardization 
of  reports  and  forms,  89  percent  of  those  interviewed  thought  that  NOHIMS  had  a 
beneficial  effect  on  standardization  (see  Table  72).  One  test  site 
administrator  believed  that  NOHIMS  had  had  no  effect  yet  on  the  standardization 
of  reports  and  forms.  A  test  site  administrator  felt  that  NOHIMS  is  also 
standardizing  input  terminology. 

One  hundred  percent  of  the  respondents  thought  that  having  timely  and 
perpetual  access  to  administrative  data  with  NOHIMS  is  very  useful  (see 
Table  73).  One  test  site  administrator  did  not  comment  on  the  usefulness  of 
timely  and  perpetual  access  to  data  because  he  felt  that  NOHIMS  did  not  have 
this  capability  yet. 
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TABLE  70 

Features/Capabilities  of  NOHIMS  That  Will  Be  Useful  in 
Administrative  Functions 

(Number  who  mentioned  feature/capability;  multiple  answers  allowed) 


NHRC 

NOHIMS 

Developers 

Higher 

Level 

Managers 

Test  Site 
Admin. 

TOTAL 

%  of 

Total  Who 
Answered 

On-line  look-up/ 
Interactive  Query 
functions 

3 

5 

4 

12 

100 

Ad  hoc  report 

generation 

capabilities 

3 

3 

4 

10 

83 

Standard  report 

generation 

capabilities 

3 

4 

2 

9 

75 

K 


m 


Assessment  of 


(N 

High 

Ma 

Greatly  increased 
Somewhat  increased 
No  effect 

Somewhat  decreased 
Greatly  decreased 


TOTAL  WHO  ANSWERED 
No  Comment 


TOTAL  INTERVIEWED 


TABLE  72 

Effect  of  NOHIMS  on  Standardizing  Reports  and  Forms 
(Number  who  mentioned  effect) 


Higher  Level 
Managers 

Test  Site 
Administrators 

TOTAL 

%  of 
Total 

Interviewed 

Beneficial  effect 

5 

3 

8 

89 

Somewhat  beneficial 
effect 

0 

0 

0 

0 

No  effect 

0 

1 

1 

11 

Somewhat  detrimental 
effect 

0 

0 

0 

0 

Detrimental  effect 

0 

0 

0 

0 

TOTAL  INTERVIEWED 

5 

4 

9 

100 

TABLE  73 

Assessment  of  the  Usefulness  of  Having  Timely  and 
Perpetual  Access  to  Administrative  Data  with  NOHIMS 
(Number  who  mentioned  rating) 


Higher  Level 
Managers 

Test  Site 
Administrators 

TOTAL 

%  of 
Total 

Interviewed 

Useful 

5 

3 

8 

100 

Somewhat  useful 

0 

0 

0 

0 

Somewhat  not 
useful 

0 

0 

0 

0 

Not  useful 


0 


0 


0 


0 


The  respondents  thought  that  NOHIMS  would  be  useful  for  a  variety  of 
administrative  functions.  The  five  functions  that  were  mentioned  most 
frequently  were  increasing  standardization  of  data  collection  forms  (mentioned 
by  100%  of  the  respondents),  manpower/resource  planning  (100%),  timely  and 
perpetual  access  to  administrative  data  (92%),  generating  administrative  reports 
(83%),  and  increasing  standardization  of  reports  (83%).  Several  people 
mentioned  that  while  NOHIMS  could  be  used  to  provide  data  for  environmental  pay 
decisions,  they  did  not  feel  this  was  an  appropriate  use  for  NOHIMS  data.  The 
major  kinds  of  data  that  will  be  useful  in  administrative  functions  included 
manpower/resource  utilization  data,  service  utilization  data,  and  hazard 
exposure  data.  All  of  the  respondents  felt  that  the  on-line  look-up/Interactive 
Query  function  in  the  industrial  component  will  be  useful  in  administrative 
functions.  The  respondents  generally  thought  that  the  NOHIMS  ad  hoc  report 
generation  capabilities  and  the  standard  report  generation  capabilities  would 
also  be  useful.  The  capabilities  of  NOHIMS  could  be  enhanced  to  make  NOHIMS 
more  useful  for  administrative  functions,  however.  Su°gestions  for  enhancements 
included  data  manipulation  functions  such  as  spreadsheet,  graphics,  and 
statistics  functions,  and  the  ability  to  test  values  of  data  items  in  the 
Interactive  Query.  The  respondents  varied  in  their  perception  of  whether  NOHIMS 
had  increased  the  amount  of  required  paperwork.  No  one  seemed  to  be  especially 
alarmed  by  the  amount  of  paperwork  required  by  NOHIMS,  however.  Eighty-nine 
percent  of  the  respondents  felt  that  NOHIMS  had  a  beneficial  effect  on  the 
standardization  of  reports  and  forms.  All  of  the  respondents  thought  that 
having  timely  and  perpetual  access  to  administrative  data  with  NOHIMS  was 
useful . 
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SECTION  VI 

EVALUATION  OF  TRANSFERABILITY  OF  NOHIMS  TO  OTHER  NAVY  INDUSTRIAL  SITES 


In  early  specifications  for  the  Navy  Occupational  Health  Information 
Management  System,  the  system  designers  placed  heavy  emphasis  on  achieving  a 
wide  range  of  applicability  for  NOHIMS  as  well  as  a  high  degree  of 
transferability  (Pugh  &  Beck,  1981;  Beck  &  Pugh,  1982).  The  designers 
endeavored  to  make  NOHIMS  equally  applicable  to  small  industrial  settings  and  to 
large  industrial  facilities.  Furthermore,  they  felt  that  NOHIMS'  extreme 
flexibility  would  allow  the  system  to  be  quickly  adapted  to  a  variety  of 
industrial  settings  and  sites.  To  accomplish  this  end,  the  NOHIMS  software  was 
designed  to  be  exportable  and  to  be  used  with  any  computer  hardware  that  can  run 
ANSI  standard  MUMPS  software. 

In  this  section  we  present  an  evaluation  of  the  transferability  of  NOHIMS 
to  other  Navy  industrial  sites.  This  evaluation  is  based  on  interviews  with  the 
NHRC  NOHIMS  developers,  higher  level  Navy  managers,  test  site  administrators, 
and  the  system  users  in  both  San  Diego,  California  and  Bremerton,  Washington  as 
well  as  on  a  description  of  features  that  make  NOHIMS  flexible  and  easily 
adaptable.  The  evaluation  of  transferability  is  covered  in  the  following  six 
subsections:  (1)  applicability  of  NOHIMS  to  other  Navy  industrial  sites,  (2) 

description  of  features  that  make  NOHIMS  flexible  and  easily  adaptable,  (3) 
description  of  implementation  process  at  the  test  sites,  (4) ■ assessment  of  how 
well  NOHIMS  adapted  to  the  information  processing  needs  at  the  test  sites, 

(5)  assessment  of  acceptability  of  NOHIMS,  and  (6)  assessment  of  transferability 
of  NOHIMS  to  other  Navy  industrial  sites. 


APPLICABILITY  OF  NOHIMS  TO  OTHER  NAVY  INDUSTRIAL  SITES 

The  interview  guide  for  evaluating  the  applicability  of  NOHIMS  to  other 
Navy  industrial  sites  contained  five  questions.  The  exact  wording  of  these 
questions  may  be  found  in  Component  29  of  Appendix  A.  Four  NHRC  NOHIMS 
developers  and  six  higher  level  Navy  managers  were  interviewed  with  this  guide. 
(One  other  higher  level  manager  was  not  given  these  questions.)  An  amalgamation 
of  their  responses  to  these  five  questions  is  presented  below. 

The  first  question  probed  for  any  differences  in  information  processing 
needs  between  the  two  test  sites  and  the  other  Navy  industrial  sites  that  will 
be  receiving  NOHIMS.  In  particular,  the  interviewees  were  asked  if  they  thought 
the  two  test  sites  (a  NARF  and  a  shipyard)  were  representative  of  the  other 
sites.  The  NHRC  NOHIMS  developers  agreed  that  general  Navy  occupational  health 
policies  are  the  same  at  all  industrial  sites  but  that  local  information 
processing  needs  and  policies  may  differ.  The  developers  acknowledged  that 
NOHIMS  will  need  to  be  customized  for  other  sites.  Where  worker  populations  are 
more  mobile  (for  example,  in  shipyards)  it  may  be  more  appropriate  to  determine 
hazardous  exposure  levels  by  process  (e.g.,  lead  worker)  rather  than  by  work 
area  surveyed.  One  developer  felt  that  the  extensive  capabilities  of  NOHIMS 
could  apply  to  operational  entities  (ships,  for  example)  as  well  as  to  Navy 
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industrial  sites.  It  was  noted  that  the  appropriateness  of  NOHIMS  for  Marine 
sites  has  not  been  addressed. 


The  higher  level  Navy  managers  were  in  agreement  also  that  the  basic  broad 
concepts  and  principles  behind  the  use  of  NOHIMS  applied  equally  well  to  all 
Navy  industrial  sites.  The  general  needs  and  functions  of  all  sites  are  the 
same,  but  there  will  be  local  differences  depending  on  the  nature  of  the 
industrial  activity.  Differences  and  similarities  were  reported  as  follows. 

All  six  NARFs  are  closely  related,  but  shipyards,  weapons  stations,  and 
public  work  centers  (PWCs)  may  operate  differently.  Public  work  centers  may  be 
harder  to  implement  because  workers  travel  to  many  different  locations  making 
the  task  of  tracking  workers  through  environments  more  difficult.  Hazards  may 
vary  from  Navy  site  to  Navy  site,  requiring  different  tests  to  monitor  the 
health  of  workers.  For  example,  the  hazards  at  the  Naval  Ocean  Systems  Center 
(NOSC)  in  San  Diego,  California  exhibit  greater  variability  than  those  at  other 
Navy  sites.  One  interviewee  speculated  that  there  may  be  a  broader  spectrum  of 
agents  there  because  it  is  an  R&D  facility  and  that  there  may  be  possible 
differences  in  data  collection  methods  because  of  tighter  security  measures. 

These  site-specific  differences  will  have  an  impact  on  the  NOHIMS 
directories.  Items  specific  to  the  information  processing  needs  of  each  site 
will  have  to  be  added  to  the  NOHIMS  directories.  However,  there  should  be  a 
common  core  of  directory  entries  used  by  all  NOHIMS  sites.  It  is  planned  that 
adherence  to  this  standardization  will  come  under  the  watchful  eye  of  the  NOHIMS 
Configuration  Control  Board. 

One  manager  saw  NOHIMS  as  being  applicable  to  shipboard  monitoring.  He 
viewed  ships  such  as  submarine  tenders,  destroyer  tenders,  and  aircraft  carriers 
as  floating  factories  with  hazardous  environments.  NOHIMS  could  be  used  to 
perform  medical  surveillance  for  personnel  on  these  ships. 

The  second  question  asked  if  NOHIMS  can  be  adapted  to  a  variety  of  Navy 
industrial  settings  and  sites  such  as  air  rework  facilities,  shipyards,  and 
public  work  centers.  As  part  of  this  same  question  interviewees  were  also  asked 
if  there  are  aspects  of  NOHIMS  that  would  make  it  unsuitable  for  any  of  these 
various  environments.  All  four  NHRC  NOHIMS  developers  concurred  that  NOHIMS  can 
be  adapted  to  a  variety  of  Navy  industrial  settings  and  sites.  However,  they 
identified  a  number  of  potential  problem  areas  that  might  arise.  The  initial 
loading  of  personnel  data  at  different  sites  may  present  a  problem  in  some 
cases.  Only  the  NARFs  have  a  Personnel  Extract  File  (PEF)  for  tracking  the 
location  of  workers.  It  may  be  difficult  to  obtain  the  necessary  personnel 
information  at  Navy  industrial  sites  other  than  NARFs.  Another  potential 
problem  area  mentioned  was  tracking  workers  in  shipyards  because  they  work  in  a 
variety  of  environments  that  can  change  rapidly.  Another  comment  was  that  the 
NOHIMS  directories  would  have  to  be  modified  for  different  sites,  but  the 
developer  who  mentioned  this  point  did  not  consider  it  to  be  a  major  problem. 

One  developer  remarked  that  if  a  site  found  certain  aspects  of  NOHIMS  unsuitable 
for  their  application,  they  did  not  have  to  use  those  features. 

In  general,  the  higher  level  managers  felt  that  NOHIMS  can  be  adapted  to  a 
variety  of  Navy  industrial  settings  and  sites  because  of  its  modular  structure. 
Obstacles  to  its  successful  adaptation  could  be  lack  of  funding,  commitment,  and 
personnel.  It  was  noted  that  occupational  health  officers  do  about  the  same 
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tasks  wherever  they  are  assigned.  One  manager  commented  that  air  rework 
facilities  and  shipyards  should  not  encounter  any  problems  since  the  workers  at 
these  sites  with  some  exceptions  are  home-based.  Personnel  at  public  work 
centers,  on  the  other  hand,  are  constantly  performing  their  work  in  a  variety  of 
locations  which  could  make  them  more  difficult  to  track.  Another  manager  felt 
that  NOHIMS  certainly  is  applicable  even  to  Naval  Supply  Centers  because 
hazardous  materials  are  stored  at  these  facilities  before  being  sent  to  Navy 
industrial  sites  and  also  because  there  are  occupational  health  units  at  Naval 
Supply  Centers.  A  minor  concern  was  expressed  by  another  manager  about  how 
NOHIMS  would  be  able  to  adapt  to  the  very  unstructured  environments  where 
shipboard  intermediate  maintenance  activities  are  performed,  citing  the  new  ship 
base  in  Everett,  Washington  as  an  example.  He  felt  that  these  unstructured, 
dirty  environments  which  afford  ample  opportunity  for  hazardous  exposures  did 
not  fall  on  the  same  continuum  as  other  Navy  industrial  sites. 

The  third  question  dealt  with  NOHIMS’  applicability  to  Navy  industrial 
settings  of  varying  sizes.  Interviewees  were  also  asked  what  limitations  or 
requirements  NOHIMS  may  have  that  relate  to  the  size  of  the  application 
environment.  All  of  the  NHRC  NOHIMS  developers  agreed  that  NOHIMS  is 
applicable  to  Navy  industrial  settings  of  varying  sizes.  One  developer  pointed 
out  that  one  of  the  great  benefits  of  the  NOHIMS  design  is  that  NOHIMS  can  grow 
to  the  size  needed.  If  there  are  any  limitations  that  relate  to  the  size  of  the 
application  environment,  these  pertain  to  the  hardware  requirements  which  are 
dependent  on  the  size  of  the  database  and  the  number  of  system  users.  The 
NOHIMS  software  is  not  limited  by  size  of  the  application  environment.  One 
developer  felt  that  NOHIMS  may  not  be  cost  effective  at  very  small  sites. 
However,  small  sites  may  be  able  to  use  a  subset  of  the  functions  in  NOHIMS. 
Another  developer  mentioned  the  potential  for  problems  in  a  multi-industry 
NOHIMS  implementation,  a  system  configuration  that  has  not  yet  been  tested.  The 
potential  problems  anticipated  would  be  performance  problems,  not  data  integrity 
problems. 

Half  of  the  higher  level  managers  answered  categorically  that  NOHIMS  is 
applicable  to  Navy  industrial  settings  of  varying  sizes.  Another  manager  was 
not  aware  of  what  problems  varying  sizes  would  present.  Several  of  the  managers 
mentioned  that  a  site  might  not  be  large  enough  to  justify  the  cost  of 
installing  NOHIMS.  Questions  raised  by  these  managers  were  how  small  can  a 
NOHIMS  configuration  be  and  what  is  the  break-off  point  in  size  where  NOHIMS 
becomes  cost  effective  to  install.  The  NOHIMS  contracted  developers  report  that 
the  smallest  NOHIMS  configuration  would  be  a  single-user  system.  Such  a 
configuration  is  suitable  for  certain  aspects  of  system  development  but  would 
not  be  appropriate  for  an  operational  system.  It  was  suggested  by  one 
interviewee  that  a  number  of  smaller  users  might  share  a  NOHIMS  system. 

In  the  fourth  question,  interviewees  were  asked  what  organizational  changes 
are  required  at  a  new  site  in  order  for  NOHIMS  to  perform  successfully. 
Specifically  they  were  asked  what  changes  to  normal  operating  methods  and 
procedures  are  required  and  what  changes  in  terminology  would  be  needed. 

Further,  they  were  asked  if  these  changes  will  present  problems  at  other  Navy 
industrial  sites.  The  NHRC  NOHIMS  developers  responded  to  this  multi-part 
question  with  a  variety  of  answers.  One  developer  stressed  the  need  to 
configure  the  NOHIMS  hardware  and  software  to  adapt  to  the  site,  pointing  out 
that  the  generality  of  NOHIMS  allows  it  to  be  adapted.  Another  developer 
focused  on  the  need  for  coordination  of  personnel  transactions  so  that  workers 


228 


may  be  properly  tracked  in  their  work  environments.  A  third  developer  mentioned 
four  areas  of  organizational  change  precipitated  by  the  advent  of  NOHIMS: 
systematic  passing  on  of  personnel  information  to  the  system;  massive  training, 
education,  and  orientation;  hiring  of  system  support  personnel  such  as  site 
managers  and  data  entry  clerks;  and  securing  the  commitment  of  higher  level 
management  that  the  information  required  to  operate  the  system  will  be 
available.  The  last  developer  interviewed  concentrated  his  attention  on 
staffing  issues.  To  be  completely  viable,  he  felt  that  NOHIMS  will  need  a 
dedicated  staff.  It  will  be  necessary  to  identify  and  train  individuals  to  work 
specifically  on  NOHIMS.  Career  paths  will  need  to  be  developed  with  incentives. 
He  also  mentioned  the  requirement  for  quality  control  of  data  entry,  possible 
through  review  by  a  higher  level  person. 

Two  of  the  higher  level  managers  felt  that  the  biggest  organizational 
change  would  be  in  the  area  of  identifying  and  securing  personnel  resources  to 
manage  and  maintain  NOHIMS.  One  of  these  managers  remarked  that  there  would  be 
no  resources  in  the  beginning  to  run  the  system,  especially  personnel.  Once 
these  people  are  on  board,  they  will  need  to  be  trained,  and  who  will  train 
them?  The  other  of  these  two  managers  expressed  the  need  to  make  someone 
responsible  for  the  operation  of  the  system,  commenting  that  it  will  require 
some  organizational  allocation  to  place  staff  in  responsible  management 
positions.  A  third  manager  noted  changes  that  have  already  occurred  at  the 
Occupational  Health  Unit  at  his  test  site  such  as  changes  in  exam  scheduling  and 
notification.  He  then  went  on  to  predict  future  changes  that  can  be  expected. 

He  felt  the  biggest  problems  to  anticipate  are  people  problems.  One  group  of 
NOHIMS  users  may  relate  well  to  the  system  while  another  group  of  users  may 
resist  introduction  of  the  system.  Which  way  it  will  go  may  be  unpredictable. 

In  order  for  the  implementation  of  NOHIMS  to  go  well,  this  manager  recommended 
that  the  technical  supervision  of  NOHIMS  should  be  closely  connected  with  the 
head  of  occupational  medicine  and  that  the  NOHIMS  site  managers  should  have 
adequate  knowledge  of  occupational  health  and  medicine  practices.  He  felt  that 
if  a  site  does  not  already  have  a  reasonably  well-developed  occupational 
medicine  program,  people  will  not  understand  what  NOHIMS  is  intended  to  do  which 
could  lead  to  resistance.  It  is  natural  to  resist  change  and/or  to  ignore  the 
system.  This  manager  concluded  that  people  will  just  have  to  get  used  to  doing 
things  differently.  Another  manager  focused  on  the  industrial  component  of 
NOHIMS,  predicting  that  NOHIMS  would  increase  communication  between  NAVMED  and 
NAVSEA  industrial  hygienist  personnel  and  between  NAVMED  industrial  sites  and 
NEHC. 


In  the  fifth  question,  interviewees  were  asked  what  changes  in  the  patterns 
of  information  exchange  and  communication  NOHIMS  will  cause  at  a  new  site  and  if 
these  changes  will  present  problems  at  other  Navy  industrial  sites.  One  NHRC 
NOHIMS  developer  thought  that  physicians  will  have  more  specific  information  on 
workers'  exposures  and  two  felt  that  there  will  be  more  information  exchange 
between  physicians  and  industrial  hygienists  (e.g.,  where  surveys  need  to  be 
conducted).  In  addition,  one  developer  noted  there  will  be  a  routine  exchange 
of  personnel  information.  Another  developer  stressed  the  need  for  hardware 
compatibility.  The  NOHIMS  hardware  should  be  standardized  to  allow  different 
sites  to  talk  to  one  another  and  the  NOHIMS  Configuration  Control  Board  should 
develop  standards  for  NOHIMS  to  ensure  cross-site  compatibility. 

One  of  the  higher  level  managers  anticipated  that  NOHIMS  would  provide  a 
more  efficient,  organized  method  of  industrial  hygiene  record  keeping.  As  he 
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noted,  "The  look-up  of  hazards  information  will  be  centralized  in  the  computer 
rather  than  having  to  leaf  through  20  to  30  books."  One  potential  problem  he 
foresaw,  however,  was  with  the  unions  who  had  complained  periodically  that  they 
did  not  have  access  to  NOHIMS  data.  He  suggested  that  a  thorough  briefing  of 
the  unions  at  a  NOHIMS  site  on  the  functions  and  capabilities  of  NOHIMS  may 
prevent  potential  problems  in  this  area.  The  major  change  expected  by  another 
manager  was  less  paper  shuffling.  The  same  manager  who  predicted  that  NOHIMS 
would  increase  communication  in  answer  to  question  four  reiterated  his 
conviction  in  answer  to  question  five  that  there  would  be  increased 
communication  between  NAVMED  and  NAVSEA  industrial  hygienist  personnel  and 
between  NAVMED  industrial  sites  and  NEHC. 


Summar\ 


The  NHRC  NOHIMS  developers  and  higher  level  managers  generally  agreed  that 
Navy  occupational  health  policies  are  the  same  at  all  industrial  sites  but  that 
local  information  processing  needs  and  policies  may  differ.  Generally,  NOHIMS 
is  suitable  for  other  air  rework  facilities,  shipyards,  public  work  centers, 
weapons  stations,  and  even  ships  and  Naval  Supply  Centers.  NOHIMS  will  need  to 
be  customized  for  these  other  sites,  however.  For  example,  the  processes  and 
criteria  used  to  determine  whether  and  when  an  employee  is  called  up  for  a 
physical  examination  may  be  different  at  other  sites,  different  examinations  or 
types  of  tests  may  be  used,  and  hazardous  agents  may  vary  from  site  to  site. 
Another  problem  that  may  arise  in  transferring  NOHIMS  to  other  sites  is  in 
obtaining  personnel  data.  Only  the  NARFs  have  a  Personnel  Extract  File  for 
tracking  the  location  of  workers.  The  worker  population  at  other  sites  may  be 
more  dynamic  than  at  the  test  sites.  New  mechanisms  for  gathering  this 
information  will  need  to  be  designed  at  non-NARF  sites.  The  higher  level 
managers  identified  lack  of  funding,  commitment,  and  limited  personnel  resources 
as  an  obstacle  to  successful  adaptation  of  NOHIMS  to  other  sites. 


Most  of  the  interviewees  agreed  that  NOHIMS  is  applicable  to  Navy 
industrial  settings  of  varying  sizes.  They  felt  that  any  limitations  that  might 
exist  would  be  hardware  related,  and  not  software  dependent.  A  few  of  the 
developers  and  managers  raised  the  issue  of  the  cost  effectiveness  of  installing 
NOHIMS  at  small  sites,  even  though  the  software  is  suitable  for  a  small  setting. 
A  developer  pointed  out  that  NOHIMS  has  not  been  tested  in  a  multi-agency 
setting  yet,  although  he  felt  that  the  potential  problems  would  be  performance 
problems,  not  data  integrity  problems. 


The  NHRC  NOHIMS  developers  had  a  variety  of  comments  about  organizational 
changes  in  operating  methods  that  are  required  at  a  new  site  in  order  for  NOHIMS 
to  perform  successfully.  They  identified  the  need  for  coordination  of  personnel 
transactions;  hiring  of  support  personnel;  securing  commitment  of  higher  level 
management;  massive  training,  education,  and  orientation;  dedicating  staff  to 
NOHIMS;  and  establishing  quality  control  of  data  entry  as  issues  to  be  addressed 
by  a  new  site.  Higher  level  managers'  comments  on  organizational  changes 
focused  on  the  need  to  identify  and  secure  personnel  resources  to  manage  and 
maintain  NOHIMS,  the  need  for  adequate  training  of  personnel,  and  designating 
responsible  management  staff.  One  manager  focused  his  comments  on  the  need  for 
close  connections  between  technical  support  and  site  managers  and  the  head  of 
occupational  medicine  to  ensure  acceptance  of  NOHIMS. 
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The  NHRC  NOHIMS  developers  and  higher  level  managers  generally  foresaw 
positive  changes  to  information  exchange  and  communication  at  new  sites.  They 
expected  increased  communication  between  physicians  and  industrial  hygienists 
and  routine  exchange  of  personnel  information.  One  manager  predicted  that 
NOHIMS  would  increase  communication  between  NAVMED  and  NAVSEA  industrial  hygiene 
personnel  and  between  NAVMED  industrial  sites  and  NEHC.  A  developer  stressed 
the  need  for  hardware  compatibility  between  sites  to  allow  for  inter-site 
communication.  Only  one  interviewee  noted  a  potential  communication  problem. 

He  foresaw  that  the  unions  may  feel  concerned  about  not  having  access  to  data 
because  it  is  stored  in  NOHIMS. 


DESCRIPTION  OF  FEATURES  THAT  MAKE  NOHIMS  FLEXIBLE  AND  EASILY  ADAPTABLE 

Component  30  of  Appendix  A  poses  a  list  of  questions  that  ask  what  features 
of  the  medical  and  industrial  components  of  NOHIMS  make  it  flexible  and 
adaptable  to  the  various  needs  at  other  Navy  industrial  sites.  The  features 
that  make  NOHIMS  flexible  and  adaptable  fall  into  seven  categories.  These  are 
NOHIMS'  omnibus  cross-referencing  feature,  directory  features,  system  set-up 
features,  data  entry  methods,  output  features,  user  friendly  features,  and 
hardware  independence  features.  The  following  discussion  presents  a  description 
of  these  various  features. 


Cross-Referencing  Feature 

NOHIMS'  omnibus  cross-referencing  feature  is  one  of  the  main  character¬ 
istics  of  the  system  that  assures  its  maximum  flexibility  and  adaptability.  The 
NOHIMS  file  structure  in  both  the  industrial  and  medical  components  provides 
pointers  from  one  type  of  data  element  to  another  within  the  component  so  that 
it  is  possible  to  track  workers  by  social  security  number  through  their  entire 
work  history  or  medical  encounters.  Thus  it  is  possible  to  retrieve  all  of  the 
environments  in  which  an  employee  has  worked,  the  industrial  activities 
employing  the  worker,  the  dates  and  time  spent  in  each  work  environment,  hazards 
existing  in  these  various  workplaces,  protective  gear  issued  to  the  worker, 
levels  of  exposure  to  hazardous  substances  and  agents,  medical  surveillance 
required  for  the  worker,  plus  medical  history  and  the  results  of  physical 
examinations  and  laboratory  tests. 

Because  of  the  vast  flexibility  inherent  in  the  design  of  NOHIMS  and  its 
extensive  cross-referencing  capability,  it  is  possible  to  ask  a  virtually 
unlimited  number  of  questions  of  the  system.  Some  examples  of  the  kinds  of 
questions  that  NOHIMS  is  capable  of  answering  are  provided  below. 

•  What  hazards  are  contained  in  a  particular  environment? 

•  For  a  particular  hazard,  what  environments  contain  this  hazard? 

•  For  a  particular  environment,  have  workers  there  been  exposed  to 

any  hazards?  If  so,  who  was  exposed?  To  which  hazards?  When? 

How  much?  Does  the  amount  of  the  exposure  exceed  the  Threshold 
Limit  Value  (TLV)  for  that  substance? 


•  Which  environments  have  experienced  exposures  of  a  particular 
hazardous  substance?  When?  In  which  of  these  environments  did  the 
exposure  exceed  the  TLV  for  that  substance? 

•  In  what  environments  has  a  particular  employee  worked?  Did  any  of 
these  environments  contain  hazards?  If  so,  which  hazards?  Has  the 
worker  been  exposed  to  any  of  these  hazards  at  a  level  that 
exceeded  the  TLV?  If  so,  when? 

•  For  a  particular  environment,  what  employees  work  there? 

•  For  a  worker  exposed  to  a  hazardous  substance,  what  are  the  values 
of  a  particular  lab  test  over  time  used  to  monitor  that  worker's 
state  of  health? 

•  What  workers  have  been  exposed  to,  say,  asbestos  in  the  last  year? 

In  what  environments  were  they  working  when  exposed? 

•  What  is  the  incidence  of,  say,  dermatitis  in  a  particular  work¬ 
place  environment  over  time  (to  be  related  to  a  list  of 
contaminants  or  hazards  present  in  that  environment  at  different 
times)? 

•  What  is  the  incidence  of,  say,  respiratory  ailments  among  all 
patients  seen  at  a  particular  branch  clinic  during  the  past  month 
compared  to  the  incidence  in  the  preceding  12  months  (to  be  related 
to  exposure  data  and  to  seasonal  variations)? 

The  list  of  questions  enumerated  above  certainly  is  not  exhaustive,  but  it 
is  illustrative  of  what  inquiries  could  be  posed  to  NOHIMS.  Many  additional 
queries  are  possible. 


Directory  Features 

Both  the  medical  and  industrial  components  of  NOHIMS  are  driven  by  codes 
stored  in  directories.  Codes  can  be  added  or  deleted  from  these  directories 
through  the  Directory  option  in  the  System  Maintenance  module  of  the  medical 
component  and  the  Directory  Maintenance  option  in  the  Maintenance  module  of  the 
industrial  component. 

In  the  medical  component ,  a  variety  of  parameters  for  the  directory  codes 
can  be  set  and/or  changed.  Each  code  must  have  a  long  name  (e.g.,  Blood 
Pressure),  but  it  also  can  have  an  abbreviated  name  (e.g.,  BP).  Both  of  these 
names  can  be  changed.  In  addition,  codes  can  be  assigned  modifiers  (e.g.,  to 
represent  different  kinds  of  chest  X-rays).  The  modifier  names  will  print  in 
various  positions  in  relation  to  the  long  name  of  the  code  depending  on  how  the 
print  position  parameter  is  set  in  the  directory,  or  printing  of  the  modifier 
name  can  be  suppressed.  Both  the  modifier  name  and  print  position  can  be 
changed.  A  number  of  input  and  output  conditions  can  be  set  for  each  code  such 
as  requiring  text  to  be  input  with  a  code  or  signifying  to  the  output  programs 
that  special  output  formatting  is  to  be  done  with  data  associated  with  the  code 
Input  and  output  conditions  can  be  changed.  Physical  examination  findings  and 
the  results  of  laboratory  tests  can  be  checked  for  valid  format,  acceptable 


values,  and  normal  ranges  with  an  additional  provijion  for  specifying  normal 
ranges  according  to  sex  and/or  age.  Result  checking  conditions  can  be  changed. 
Help  text  may  be  associated  with  a  code  and  invoked  by  entering  a  question  mark 
when  the  data  entry  clerk  is  being  prompted  to  enter  results.  The  help  text  can 
be  changed.  Flowcharts  can  be  triggered  by  the  presence  of  a  code  in  the 
patient's  medical  record.  For  example,  if  a  patient  has  been  given  the 
diagnosis  of  Hypertension,  NOHIMS  can  be  triggered  to  produce  a  Hypertension 
flowchart  whenever  the  patient's  medical  record  is  displayed  or  printed.  The 
flowchart  trigger  can  be  deleted  if  it  no  longer  is  desired.  Listcodes  group 
together  commonly  ordered  sets  of  laboratory  tests  such  as  a  SMAC,  a  Complete 
Blood  Count  (CBC)  with  Differential,  and  Electrolytes.  The  order  that  the 
individual  tests  follow  for  each  Listcode  can  be  set  up  to  match  the  order  in 
which  the  test  results  appear  on  the  lab  chit  in  use,  thus  facilitating  data 
entry.  The  order  for  individual  tests  in  Listcodes  can  be  changed.  With  the 
ability  to  add  codes  to  the  medical  component  directory  and  the  inherent 
flexibility  just  described  in  setting  the  parameters  associated  with  each  code, 
the  system  manager  can  tailor  the  medical  component  to  meet  the  specific  needs 
of  the  operational  site  being  served  by  NOHIMS. 

The  industrial  component  of  NOHIMS  contains  a  directory  system  similar  in 
operation  to  that  of  the  medical  component  in  that  all  features  described  for 
the  medical  component  directory  also  apply  to  the  industrial  component 
directory.  The  directory  allows  any  number  of  synonymous  names  to  be  defined 
for  a  code  as  well  as  a  primary  name  and  an  abbreviation.  This  design  feature 
allows  retrieval  and  identification  of  directory  codes  or  elements  using  local 
or  popular  synonyms.  For  example,  Methyl  Ethyl  Ketone  can  be  identified  by  its 
popular  acronym  MEK  and  Acronitrile  will  also  be  found  as  Vinyl  Cyanide. 

The  industrial  component  directory  has  ten  distinct  data  types.  This 
feature  allows  definition  of  codes  that  are  names,  results,  modifiers,  panel 
codes,  free  text  documents,  dates,  and  times.  It  also  includes  a  variety  of 
translated  key  to  text  or  value  data  codes,  a  user-defined  data  classification 
code  type,  and  a  code  type  that  permits  definition  of  subdirectories  of 
associated  names  such  as  chemical  manufacturers,  occupations,  or  safety 
equipment  lists.  The  hazardous  agent  table  of  the  industrial  component  is 
actually  a  one-code  subdirectory  within  the  main  directory  wherein  each  chemical 
agent  is  defined  as  a  member  or  element  of  the  "HAZARDOUS  AGENT"  subdirectory 
code.  NOHIMS  has  complete  definition,  editing,  deletion,  filing,  selection,  and 
retrieval  capabilities  for  both  directory  and  subdirectory  codes.  The  document 
type  of  code  can  be  defined  with  both  document  length  and  line  width  parameters. 
The  text  for  document  type  codes  is  entered  and  edited  via  the  industrial 
component  text  editors.  The  classification  type  of  code  allows  the  user  to 
devise  and  use  a  coding  scheme  to  categorize  data  having  a  multitude  of 
associated  attributes.  The  directory  also  facilitates  control  of  recurrent 
input  of  a  data  item  where  multiple  response  input  or  multiple  subdirectory 
member  selection  is  applicable. 

Using  the  TABLES  suboption,  the  system  manager  may  add  or  delete  codes  from 
the  system  translation  tables  or  change  the  textual  name  associated  with  a  given 
code.  These  tables  cover  medical  history  examination  codes,  medical  laboratory 
examination  codes,  medical  physical  examination  codes,  sample  media  codes, 
concentration  scales  and  units,  medical  examination  applicability  flag  codes, 
occupation  codes,  physical  restrictions  codes,  body  part  and  organ  systems 
codes,  and  mandatory  medical  requirement  codes. 
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One  of  the  initial  tasks  in  implementing  NOHIMS  at  a  site  is  to  identify 
the  system  users.  Both  the  medical  and  industrial  components  of  NOHIMS  allow 
flexibility  in  setting  up  the  identification  files  for  the  users.  Each  user  may 
select  a  unique  ID  code  of  from  three  to  five  characters  to  be  entered  when 
logging  onto  the  system.  The  first  three  characters  of  the  ID  code  are  also 
used  to  uniquely  identify  the  user  in  the  system.  In  the  industrial  component, 
the  system  manager  may  also  select  the  system  options  to  which  the  given  user 
will  have  access.  In  the  medical  component,  the  system  manager  defines  user 
classes  such  as  system  managers,  providers,  and  data  entry  clerks  and  then 
specifies  which  options  may  be  accessed  by  that  class  of  user.  Each  individual 
user  is  assigned  to  a  class  of  users  and  is  thereby  limited  to  the  access 
options  of  that  class  of  users.  The  ID  file  in  the  medical  component  is  also 
used  for  alphabetic  look-up  of  providers'  names  during  encounter  entry.  In  both 
components  of  NOHIMS,  the  system  manager  may  edit  the  ID  file  at  any  time  and 
may  activate/de-activate/re-activate  users  as  required  for  his/her  site.  There 
is  no  practical  limit  to  the  number  of  users  that  may  be  entered  into  the  ID 
files. 

The  industrial  component  is  also  flexible  in  the  definition  of  the  agency 
structure.  During  system  implementation,  the  structure  of  the  agency  to  be 
served  is  defined.  As  many  organizational  levels  (for  example,  departments  and 
divisions)  as  required  may  be  defined,  regardless  of  how  scattered  geograph¬ 
ically  they  may  be  or  the  size  of  the  agency.  Within  these  organizational 
levels,  any  number  of  units  or  groups  may  be  defined.  There  are  no  limitations 
on  how  the  organizational  branches  may  be  named.  The  Edit  Organization  option 
of  the  Agency  Data  module  allows  the  system  users  to  change  names,  acronyms,  or 
codes  for  any  of  the  groups  within  the  organization  once  the  system  is 
operational.  It  also  allows  the  user  to  add  groups  to  or  delete  groups  from  the 
organization  as  necessary.  Any  alterations  that  are  made  are  reflected 
throughout  the  applicable  levels  of  the  agency's  hierarchical  structure. 

Data  Entry  Features 

The  medical  component  of  NOHIMS  does  not  come  with  a  standard  patient 
registration  form  because  only  three  data  elements  must  be  collected  during 
registration — the  patient’s  name,  sex,  and  date  of  birth.  Each  NOHIMS  site  can 
collect  other  registration  data  elements  as  needed.  The  System  Maintenance 
module  in  the  medical  component  tells  NOHIMS  which  data  elements  are  to  be 
collected,  in  what  order  they  are  to  be  collected,  and  how  the  registration  data 
are  to  be  displayed  on  the  CRT  screen.  These  parameters  may  be  changed  at  any 
time  through  the  System  Maintenance  module.  A  patient  must  be  registered  in 
NOHIMS  before  encounter  data  can  be  entered  in  the  patient's  medical  record. 

Medical  encounter  entry  has  very  few  constraints.  The  encounter  format 
contains  two  parts — the  Header  and  the  Body.  The  Header  contains  primarily 
administrative  information  that  identifies  the  patient,  the  date  and  site  of  the 
encounter,  the  name  of  the  care  provider(s),  and  the  nature  of  the  visit  and 
service  provided.  The  order  of  data  items  in  the  Header  of  a  medical  encounter 
in  NOHIMS  is  fixed.  Entry  of  data  items  in  the  Body  of  the  medical  encounter 
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can  be  in  any  order;  however,  the  order  of  data  entry  should  follow  the  items  on 
the  medical  encounter  forms.  Lab  test  codes  can  be  entered  at  the  time  of  the 
encounter;  lab  results  can  be  added  to  the  patient  record  when  they  are 

received.  Single  result  tests  can  be  added  in  any  order.  Listcode  panels  and 

multiple  result  tests  must  be  entered  in  the  sequence  that  they  are  set  up  in 

the  medical  component  directory  or  entry  routines.  The  sequence  of  the  Listcode 

panels  can  be  changed  through  the  System  Maintenance  module.  If  any  errors  or 
omissions  are  noted  in  a  patient's  medical  record,  they  can  be  corrected  at  any 
time  through  the  Medical  Edit  option  in  the  medical  component  of  NOHIMS. 

An  already  existing  numbering  scheme  can  be  used  for  identifying  patient 
records  including  social  security  number.  This  number  becomes  the  unit  number 
in  the  medical  component  of  NOHIMS.  Patients  can  be  looked  up  by  either  name 
or  social  security  (unit)  number.  In  the  medical  component  of  NOHIMS,  there  is 
a  choice  as  to  how  codes  can  be  entered  in  order  to  balance  ease  of  data  entry 
with  ease  of  use  by  care  providers.  Codes  may  be  entered  by  using  the  long 
name,  a  subset  of  the  long  name,  the  short  name,  or  the  internal  code  of  a 
particular  data  item.  The  San  Diego  test  site  generally  uses  the  short  name  of 
the  data  item.  A  NOHIMS  site  can  develop  as  many  different  medical  encounter 
forms  and  laboratory  results  input  documents  as  are  needed  to  collect  the 
required  information  for  data  entry. 

Data  other  than  directory  codes,  such  as  free  text,  can  be  entered  in  the 
data  files  of  the  medical  component.  Status  codes  that  define  the  status  of  a 
diagnosis  or  problem  such  as  History  Of,  Rule  Out,  Presumptive,  Major,  and 
Inactive  can  be  included.  Physical  findings  and  laboratory  test  results  can 
be  entered  in  the  patient  record  in  any  format.  Processing  of  narrative  data, 
however,  increases  both  data  entry  time  and  disk  storage  requirements; 
therefore,  discretion  in  using  narrative  data  is  essential.  Also,  it  is 
difficult  to  summarize  or  analyze  textual  entries. 

The  maximum  number  of  patients  that  can  be  registered  in  a  single  medical 
component  of  NOHIMS  is  6,759,999.  The  maximum  number  of  medical  encounters  that 
can  be  stored  at  one  time  for  a  single  patient  is  999.  The  maximum  number  of 
different  directory  codes  (excluding  code  modifiers)  allowable  in  the  medical 
component  is  121,670.  These  limits  are  so  large  that  in  practice  they  normally 
are  never  reached.  A  more  likely  limiting  factor  would  be  the  amount  of  disk 
storage  space  that  is  available.  However,  when  NOHIMS  approaches  a  fully  loaded 
disk  state,  inactive  and/or  older  patient  records  can  be  archived  to  tape  to 
free  up  disk  space,  disks  can  be  reorganized,  or  additional  disks  can  be 
purchased. 

In  the  industrial  component  of  NOHIMS,  data  entry  sequences  for  survey 
data,  hazardous  agent  information,  environment  data,  and  personnel  data  follow 
either  a  set  of  standardized  input  documents  or  a  minimum  required  entry  set.  A 
set  of  standard  input  documents  is  used  by  the  industrial  hygienists  to  first 
collect  data  during  a  survey  of  an  environment  and  then  to  enter  or  update  the 
survey  data  in  NOHIMS.  When  entering  survey  data  in  NOHIMS,  the  data  entry 
person  may  enter  as  many  Occupational  Hazard  Data  Sheets  and  as  much  Material 
Inventory  data  as  is  required  to  complete  the  survey  information.  The  hazardous 
agent  information  is  also  input  from  a  standard  data  collection  form  while  the 
other  major  data  areas — personnel  and  environments — require  the  entry  of  only 
a  basic  set  of  identification  data  items. 
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Additional  input  capabilities  are  facilitated  by  associating  user-designed 
input  sequences  with  any  of  the  existing  entry  options.  The  input  sequences  are 
created  by  selecting  any  number  and  order  of  the  industrial  component's 
directory  codes  to  be  entered.  Any  number  of  sequences  may  be  defined  and 
associated  with  any  entry  process.  The  same  data  item  may  be  used  in  more  than 
one  input  sequence  for  different  purposes  without  conflict  or  confusion.  For 
example,  the  directory  code  for  an  agent  concentration  measurement  may  appear  in 
the  survey  data  input  sequence  denoting  the  concentration  value  from  a  survey  in 
an  environment.  The  same  directory  code  may  also  appear  in  the  personnel  input 
sequence  and  denote  a  concentration  value  to  which  an  individual  worker  was 
exposed.  These  two  data  items,  identical  in  name  and  description  but  not  in 
value,  will  not  be  confused  with  one  another  in  NOHIMS  since  one  value  is 
associated  only  with  the  personnel  entry  function  and  the  other  value  is 
associated  only  with  the  survey  entry  function.  The  input  sequence  definition, 
edit,  and  association  processes  are  all  accessed  through  the  Directory 
Maintenance  options  of  the  Maintenance  module. 

In  addition  to  the  flexibility  in  the  input  sequences,  the  industrial 
component  provides  flexibility  in  the  definition  of  environments,  worker 
assignments,  survey  indexes,  and  hazardous  agents.  The  Environment  Data  module 
compiles  a  list  of  all  environments  contained  in  the  agency.  In  general,  an 
environment  may  be  anything  that  can  be  surveyed  so  NOHIMS  allows  three 
different  types  of  environments  to  be  defined.  These  types  are  locations  (a 
physical  location  such  as  BLDG  150,  ROOM  A,  Painting  Area),  events  (a  unique  or 
unusual  occurrence  with  an  environmental  impact  such  as  a  spill  or  leak),  and 
occupations  or  programs  (such  as  corrosion  control  or  the  respirator  fit 
program). 

In  the  Personnel  Data  module,  a  variety  of  worker  assignments  can  be 
managed  by  NOHIMS.  A  given  worker  may  be  assigned  to  any  agency  organizational 
level,  to  work  environments  associated  with  other  agencies,  and  to  multiple  work 
environments.  These  relationships  may  be  established,  altered,  and  terminated 
at  any  time.  The  local  site  may  identify  user-specified  recommendations  or 
other  local  requirements  to  be  considered  in  determining  appropriate  medical 
monitoring. 

Flexibility  is  inherent  in  the  Survey  Data  module  in  that  survey  data  may 
be  defined  for  any  number  or  type  of  environments.  Local  conventions  for 
indexing  or  referencing  a  survey  may  be  used  to  identify  a  survey  in  NOHIMS. 

Additional  hazardous  agents  specific  to  a  given  site  may  be  defined  in 
NOHIMS  using  the  Hazard  Data  Entry  option  in  the  Hazard  Data  module.  All 
hazardous  agents  may  be  identified  by  as  many  synonymous  names  as  needed. 
Hazardous  agent  concentrations  and  exposure  limits  for  a  variety  of  authorities 
and  sampling  scales  may  be  maintained  in  NOHIMS.  NOHIMS  stores  PEL,  TLV,  and 
NIOSH  exposure  limits,  and  TWA,  ACTION  LEVEL,  STEL,  and  CEILING  limits  for 
agents,  if  applicable. 

A  worker  in  the  industrial  component  can  be  identified  by  either  name, 
social  security  number,  local  employee/pay  number  or,  in  some  instances,  the 
agency  unit  to  which  the  worker  is  assigned.  There  are  no  intrinsic  limits  on 
the  number  of  personnel,  hazardous  agents,  environments,  surveys,  or  the  size  or 
organizational  structure  of  the  industry. 
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NOHIMS  produces  a  number  of  standard  reports  whose  format  and  content 
(types  of  information  contained)  cannot  be  changed  without  programming 
intervention.  In  the  medical  component  these  patient-specific  hard-coded 
reports  are  the  Encounter  Report,  the  Status  Report  (a  summary  of  the  patient's 
medical  record),  and  the  Index  Patient  (an  index  to  all  of  the  sections  of  a 
patient's  medical  record).  The  industrial  component  also  has  several  hard-coded 
reports,  namely,  the  Industrial  Hygiene  Survey  Report,  the  Physical  Exam 
Notification  Report,  the  Occupational  Health  Examination  Roster,  and  the 
Individual  Exposure  Examination  Report. 

In  addition  to  the  standard,  hard-coded  reports  in  the  medical  component  of 
NOHIMS,  however,  there  are  a  number  of  patient-specific  reports  whose  format  and 
content  can  be  specified  and  altered  if  necessary  through  the  use  of  System 
Maintenance  options.  The  registration  display  (which  can  be  printed  as  a 
report)  is  set  up  and  can  be  changed  through  the  Registration  Functions  option. 
The  content  and  format  of  the  Patient  Summary  report  is  set  up  and  can  be 
changed  through  the  Medical  Data  Functions  option.  Templates  for  standard 
flowcharts  are  created  and  can  be  edited  through  the  Directory  option.  There  is 
also  an  Interactive  Flowchart  function  that  allows  a  NOHIMS  user  to  create  an  ad 
hoc  flowchart  for  a  patient.  When  a  NOHIMS  user  wishes  to  produce  reports 
involving  more  than  one  patient,  the  Report  Generator  in  the  medical  component 
is  invoked.  This  module  allows  the  user  to  select  subsets  of  patients  or 
visits,  and  to  list  and/or  cross-tabulate  the  data  items  retrieved.  The  data 
items  to  be  included  in  Report  Generator  runs  can  be  defined  and  edited  by  the 
report  user.  The  general  report  format  cannot  be  changed  without  programmer 
intervention,  however.  The  NOHIMS  medical  component  cannot  create  ad  hoc 
reports  in  any  format  desired  with  any  content  desired  nor  does  the  medical 
component  have  an  interactive  query  function. 

The  industrial  component  contains  cross-referenced  data  retrieval  options 
for  normal  displays  for  all  of  the  general  data  areas.  As  an  example,  when 
displaying  the  organizational  units  of  an  agency,  the  user  may  also  elect  to 
include  the  work  environments  associated  with  each  agency  unit  and  a  list  of  the 
personnel  assigned  to  each  agency  unit  in  the  display. 

The  Query/Report  function  can  retrieve  any  or  all  of  the  current  data 
within  the  industrial  component  in  any  user-selected  order  that  is  consistent 
with  the  cross-referencing  paths  of  the  five  data  areas.  The  construction  of  a 
query  is  a  step-by-step  menu  selection  process  wherein  the  user  is  provided  a 
menu  of  the  data  areas  and  data  items  that  are  internally  linked  to  the 
previously  selected  data  areas.  The  industrial  component  Query/Report  module 
does  not  require  system  maintenance  when  new  codes  are  added  to  or  data  items 
are  changed  in  the  system.  The  Query/Report  will  detect  new  or  altered  input 
sequences  or  directory  codes  and  adjust  itself  to  being  capable  of  retrieving 
these  data  in  appropriate  ways.  The  display  format  is  fixed. 

User  Friendly  Features 

The  medical  and  industrial  components  of  NOHIMS  have  several  features  that 
make  NOHIMS  easy  to  learn  and,  therefore,  easily  adaptable  to  new  installations. 
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These  are  its  menu-driven  design,  on-line  help  text,  supporting  user  documen¬ 
tation,  and  job  aids.  In  both  the  medical  and  industrial  components,  all  system 
options  are  identified  and  invoked  through  menu  selection  processes.  A  user  may 
easily  move  forward  and  backward  through  menu  levels,  usually  with  a  single 
character  keystroke.  The  user  is  allowed  to  enter  a  "?"  character  when  in  doubt 
of  the  proper  response  to  any  system  prompt.  NOHIMS  will  then  provide  the  user 
with  either  an  explanation  of  the  proper  response,  a  list  of  applicable 
responses,  and/or  instructions  on  how  to  obtain  additional  help.  A  Question 
Mark  Response  suboption  in  the  Directory  option  of  the  medical  component  allows 
the  system  manager  to  create  and  edit  help  text  for  the  medical  component.  A 
Response-to-?  suboption  in  the  Maintenance  module  of  the  industrial  component 
allows  the  system  manager  to  augment  or  edit  responses  to  a  user's  "?"  entry  at 
industrial  component  system  prompts. 

User  manuals/guides  are  available  for  both  the  medical  and  industrial 
components  of  NOHIMS.  Several  job  aids  were  designed  to  aid  data  entry  clerks 
in  entering  medical  data  into  the  system.  These  are  contained  in  the  system 
user's  guide  for  the  medical  component.  A  system  manager's  manual  also  is 
available  for  each  component.  The  Assessment  of  Operational  Characteristics 
subsection  in  the  Evaluation  of  NOHIMS  System  Design  section  of  this  report 
contains  further  information  on  NOHIMS'  user  friendly  features. 


Hardware  Independence  Features 


A  variety  of  hardware  configurations  can  support  NOHIMS.  A  number  of 
minicomputers  can  be  used  to  run  NOHIMS  including  both  the  DEC  PDP  11  series  and 
the  VAX  series,  Plessey,  Harris,  Tandem,  Prime,  Data  General,  and  Convergent 
Technologies  (and  CT  look-alikes).  For  smaller  NOHIMS  sites,  the  software  will 
run  on  a  variety  of  microprocessors  including  the  IBM  PC/AT  (and  its  clones), 
COMPAQ,  Motorola,  NCR,  Tandy,  and  Olivetti. 


NOHIMS  can  accommodate  a  variety  of  terminal/cursor  types  including  any 
hard  copy  device,  Infoton  standard  or  Vistar  with  number  pad,  dumb  terminals, 
and  smart  terminals.  NOHIMS  at  this  point  in  time  does  not  support  terminals 
with  split-screen  features. 


Both  components  of  NOHIMS  have  features  that  make  NOHIMS  flexible  and 
adaptable  to  needs  at  other  Navy  industrial  sites.  These  are  the  omnibus  cross- 
referencing  ability  of  NOHIMS,  directory  features,  system  set-up  features,  data 
entry  features,  output  features,  user  friendly  features,  and  hardware 
independence  features.  The  omnibus  cross-referencing  ability  of  both  the 
industrial  and  medical  components  of  NOHIMS  assures  maximum  flexibility  and 
adaptability  to  varying  data  retrieval  needs.  NOHIMS  can  retrieve  correlated 
data  items  within  a  component,  making  it  possible  to  follow  workers  through 
their  work  or  medical  history,  or  to  ask  an  unlimited  variety  of  questions  such 
as  what  hazards  are  in  a  particular  environment. 


The  directories  of  the  medical  and  industrial  components  also  provide 
flexibility  and  adaptability.  A  variety  of  data  types  can  be  defined  and 
various  parameters  of  the  data  items  such  as  primary  name  and  synonymous  names 
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can  be  defined  and  modified  through  directory  functions  as  required  by  an 
application  site. 

NOHIMS  allows  flexibility  in  the  definition  and  maintenance  of  the  system 
user  identification  file.  User-specified  ID  codes  and  access  options  may  be  set 
and  changed.  The  industrial  component  initial  agency  definition  process  allows 
definition  of  the  agency  structure  according  to  local  needs.  The  organizational 
structure  and  titles  may  be  modified  as  required  by  the  operational  site. 

Many  of  the  data  entry  sequences  in  NOHIMS  can  be  set  up  and  altered  by  the 
system  manager.  In  the  medical  component,  the  system  manager  can  alter  the 
registration  sequence  through  System  Maintenance  functions.  The  data  entry 
sequence  for  the  Header  of  an  encounter  is  fixed;  however,  the  data  entry 
sequence  for  the  Body  of  an  encounter  is  not.  Data  in  the  Body  of  the  encounter 
may  be  entered  in  any  order.  The  input  parameters  for  each  code  are  set  and 
altered  through  the  Directory  Maintenance  option  in  the  Systems  Maintenance 
module.  An  already  existing  numbering  scheme  may  be  used  for  identifying 
patient  records,  including  the  social  security  number.  A  variety  of  data  types, 
codes,  free  text,  test  results,  and  statuses  (such  as  abnormal  or  major)  may  be 
entered.  There  are  no  practical  limits  on  the  number  of  encounters  and 
directory  codes  that  can  be  entered  into  the  system;  disk  storage  space  is 
usually  the  limiting  factor. 

In  the  industrial  component,  survey  data  and  hazardous  agent  data  items  are 
entered  in  sequence  from  standard  data  collection  forms.  As  many  Occupational 
Hazard  Data  Sheets  and  as  much  Material  Inventory  data  as  required  to  complete 
the  survey  may  be  entered.  The  personnel  and  environment  data  options  use  a 
standard  set  of  entry  items.  Ad  hoc  input  sequences  may  be  defined  by  the  user 
and  associated  with  any  of  the  system  entry  functions.  Data  items  may  be  used 
in  more  than  one  input  sequence.  Environments  may  be  defined  as  either  a 
location,  an  event,  or  an  occupation  or  program.  A  variety  of  worker 
assignments  can  be  managed  by  NOHIMS  including  multiple  work  environments  and 
multiple-agency  assignments.  Local  requirements  may  be  used  to  define  medical 
monitoring  recommendations.  Local  conventions  may  also  be  used  for  naming 
environments,  workplace  locations,  and  for  identifying  surveys.  Additional 
hazardous  agents  may  be  added  to  the  Hazardous  Agent  Table.  A  variety  of 
exposure  limits  and  sampling  scales  may  be  maintained  in  NOHIMS. 

The  medical  component  produces  several  reports  whose  content  and/or  format 
can  be  altered  or  defined  by  the  end  user.  These  include  the  Patient  Summary, 
Flowchart,  Interactive  Flowchart,  and  the  COSTAR  Report  Generator.  The 
industrial  component  contains  cross-referenced  data  retrieval  options  in  all 
system  modules  in  addition  to  the  standard  display  of  the  data  of  that  module. 
The  user  may  define  the  content  of  the.se  displays  within  the  parameters  of  the 
system  module.  The  user  may  also  deEine  data  retrieval  tasks  using  the 
Query/Report  module;  however,  the  format  of  a  query  is  fixed. 

The  medical  and  industrial  components  of  NOHIMS  have  several  features  that 
make  NOHIMS  easy  to  learn  and,  therefore,  easily  adaptable  to  new  installations. 
These  are  its  menu-drive  design,  on-line  help  text,  supporting  user  documen¬ 
tation,  and  job  aids. 
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Finally,  NOHIMS  is  flexible  and  adaptable  because  a  variety  of  mini-  and 
microcomputers  can  support  NOHIMS.  NOHIMS  can  also  accommodate  a  variety  of 
terminal/cursor  types. 


DESCRIPTION  OF  IMPLEMENTATION  PROCESS  AT  THE  TEST  SITES 

The  implementation  of  NOHIMS  at  the  two  test  sites  was  an  involved  process 
that  required  significant  resources  and  efforts.  In  this  section  we  have 
documented  the  personnel  involved  in  the  implementation  process  at  the  test 
sites,  the  steps  involved  in  implementing  NOHIMS,  problems  that  were  encountered 
in  implementing  NOHIMS,  the  effects  of  NOHIMS  installation  on  staff  morale,  and 
current  operational  procedures  at  the  two  test  sites.  Component  31  of  Appendix 
A  contains  the  questions  that  we  used  to  solicit  this  information.  It  is  our 
hope  that  a  thorough  documentation  of  the  implementation  process  at  the  test 
sites  will  give  future  NOHIMS  implementors  and  personnel  at  installation  sites 
an  accurate  assessment  of  the  work  that  will  be  involved  in  implementing  NOHIMS, 
the  resources  that  will  be  required,  and  the  problems  that  may  be  encountered  in 
the  process. 

Of  the  two  test  sites,  the  implementation  process  in  San  Diego,  California 
was  more  involved  than  that  in  Bremerton,  Washington  for  several  reasons. 

First,  San  Diego  was  the  pilot  test  site  where  both  the  industrial  and  medical 
compone: ts  of  NOHIMS  were  developed.  A  variety  of  Navy  personnel,  civilian 
employees,  and  contractors  all  took  part  in  the  implementation  process  in  San 
Diego.  Only  the  industrial  component  of  NOHIMS  was  implemented  in  Bremerton, 
involving  fewer  people  and  less  system  resources. 

Individuals  and  Steps  Involved  in  the 
Implementation  Process  in  San  Diego,  California 

Even  before  the  implementation  process  was  begun  in  San  Diego,  a  comprehen¬ 
sive  systems  analysis  of  the  record  keeping  and  reporting  requirements  of  the 
North  Island  Naval  Air  Rework  Facility  (NARF)  was  conducted  to  develop 
preliminary  specifications  for  collecting,  processing,  and  displaying  medical 
and  environmental  data  within  a  prototype  occupational  health  information  system 
(Pugh  &  Beck,  1981).  As  a  result  of  the  systems  analysis,  a  semi-automated 
interim  system  (described  in  another  section  of  this  report)  was  implemented  to 
test  NOHIMS  design  concepts  and  to  provide  a  temporary  capability  to  produce 
certain  basic  reports  needed  for  management  of  occupational  health  activities. 

In  the  ensuing  year,  functional  specifications  for  a  fully  automated  Navy 
Occupational  Health  Information  Management  System  were  developed  (Beck  &  Pugh, 
1982).  Lawrence  A.  Hermansen  and  Michael  J.  Gorney  of  the  Naval  Health  Research 
Center  (NHRC)  assisted  Donald  D.  Beck  and  William  M.  Pugh  in  maintaining  the 
interim  system.  Richard  L.  Cohen,  M.D.  provided  much  needed  med..  al  information 
during  the  design  phase.  Anne  K.  Burton  was  instrumental  in  the  development  of 
the  Industrial  Hygiene  Survey  Form,  and  Captain  Charles  W.  Bollinger  contributed 
to  the  industrial  hygiene  procedure  methodology. 

The  systems  analysis  was  conducted  by  staff  from  the  Environmental  Medicine 
Department  of  NHRC  spearheaded  by  William  Pugh  and  Donald  Beck.  Many 
individuals  assisted  NHRC  in  collecting  the  data  needed  for  the  systems 


analysis,  including  Captain  Thomas  V.  McManaman,  Commander  Chris  Holmes,  Andrew 
L.  Bryson,  Anne  Burton,  and  other  staff  members  of  the  Environmental  Health 
Service,  San  Diego  Regional  Medical  Center;  Captain  John  Osborne,  Lieutenant 
Tyrone  Cormier,  Alan  M.  Watanabe,  and  other  staff  members  of  the  Environmental 
Health  Service,  Naval  Regional  Medical  Clinic,  Hawaii;  Captain  Richard  Nelson, 
Dr.  Glenn  H.  Randall,  and  other  staff  members  of  the  Navy  Environmental  Health 
Center,  Norfolk,  Virginia;  HMCM  W.  H.  Anders  and  other  staff  members  of  the  NRMC 
Branch  Clinic,  NAS,  North  Island,  San  Diego;  and  Matt  Rosa,  Safety  and  Health 
Manager,  Naval  Air  Rework  Facility,  NAS,  North  Island,  San  Diego. 

The  functional  specifications  for  the  NOHIMS  software  led  to  adapting 
public  domain  COSTAR  (Computer  STored  Ambulatory  Record)  as  the  medical 
component  of  NOHIMS  and  writing  completely  new  MUMPS  software  to  implement  the 
industrial  component.  These  technical  and  programming  services  were  provided  by 
R-K  Research  and  System  Design,  Malibu,  California  and  The  MITRE  Corporation, 
McLean,  Virginia  under  contract  to  NHRC.  Key  contract  personnel  contributing  to 
the  development  of  NOHIMS  were  Donald  D.  Beck  for  the  industrial  component,  and 
Diane  M.  Ramsey-Klee,  Ph.D.,  Kathryn  E.  Guidera,  MSPH,  and  Anton  S.  Roberts  for 
the  medical  component . 

The  development  of  forms  to  capture  data  for  input  to  NOHIMS  was  also  a 
team  effort.  Anne  Burton,  Larry  Brady,  William  Pugh,  Lawrence  Hermansen,  and 
Donald  Beck  collaborated  to  develop  methods  for  collecting  industrial  hygiene 
survey  data.  On  the  medical  side  of  NOHIMS,  patient  registration  and  medical 
encounter  forms  were  developed  jointly  by  Richard  Cohen,  M.D.,  Diane  Ramsey- 
Klee,  and  Kathryn  Guidera  with  additional  input  from  Merle  Bundy,  M.D.,  Lois 
Moody,  R.N.,  Margie  Acol,  and  Jenny  Early.  Medical  history  and  occupational 
history  forms  were  developed  by  Richard  Cohen,  M.D.,  James  C.  Helmkamp,  Ph.D., 
Diane  Ramsey-Klee,  Kathryn  Guidera,  and  Craig  M.  Bone. 

NOHIMS  hardware  and  software  installation  in  San  Diego  was  accomplished  by 
William  Pugh,  Donald  Beck,  Lawrence  Hermansen,  and  Michael  Gorney.  NOHIMS 
system  testing  was  performed  by  Donald  Beck,  William  Pugh,  Diane  Ramsey-Klee, 
Kathryn  Guidera,  Lawrence  Hermansen,  Anne  Burton,  and  by  the  data  entry  clerks. 
Necessary  software  modifications  were  made  by  Anton  Roberts,  Kathryn  Guidera, 
Donald  Beck,  Jack  Frogue,  Diana  Hamilton,  and  Mark  Lauterern. 

NOHIMS  documentation  for  system  users  and  the  system  managers  was  prepared 
by  Diane  M,  Ramsey-Klee,  Kathryn  Guidera,  Donald  Beck,  and  Lawrence  Hermansen. 
Although  NOHIMS  training  was  not  included  in  contract  work  statements,  a  minimal 
amount  of  training  had  to  be  conducted  at  the  time  that  NOHIMS  became 
operational  at  the  two  test  sites.  In  San  Diego  training  initially  was  provided 
by  Kathryn  Guidera,  Diane  Ramsey-Klee,  and  Donald  Beck,  and  later  by  Lawrence 
Hermansen  in  his  role  as  NOHIMS  system  manager. 

A  number  of  technical  reports  were  published  to  document  the  design, 
development,  installation,  and  implementation  phases  of  NOHIMS.  These  reports 
were  authored  by  William  Pugh,  Donald  Beck,  Diane  Ramsey-Klee,  Lawrence 
Hermansen,  James  Helmkamp,  Richard  Cohen,  M.D.,  Kathryn  Guidera,  and  Craig  Bone. 

The  Functional  Manager  of  the  NOHIMS  project  for  the  Naval  Medical  Research 
and  Development  Command,  Bethesda,  Maryland  has  been  Commander  Patrick  A. 

Truman.  Commander  James  W.  Allen,  Navy  Environmental  Health  Center,  Norfolk, 
Virginia  has  been  the  NOHIMS  Project  Manager.  Management  of  NOHIMS'  design  and 
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development  for  the  Naval  Health  Resarch  Center,  San  Diego,  California  has  been 
the  responsibility  of  William  M.  Pugh,  Head,  Medical  Information  Systems 
Program.  Lawrence  Hermansen  serves  as  the  NOHIMS  system  manager  for  the  San 
Diego  test  site  on  a  full-time  basis  with  the  assistance  of  Diana  Hamilton. 


Individuals  and  Steps  Involved  in  the 
Implementation  Process  in  Bremerton.  Washington 

In  the  design  phase  of  NOHIMS,  Captain  Charles  W.  Bollinger  [Director, 
Occupational  and  Environmental  Health  Services,  located  at  the  Puget  Sound  Naval 
Shipyard,  under  the  Naval  Hospital,  Bremerton,  Washington]  became  involved  in 
early  development  of  system  design  concepts  and  industrial  hygiene  procedure 
methodology.  He  was  instrumental  in  persuading  Navy  management  to  select 
Bremerton  as  the  second  test  site  for  NOHIMS. 

It  was  decided  to  initially  implement  only  the  industrial  component  at 
Bremerton.  Harvey  Grasso,  an  industrial  hygienist,  defined  the  organizational 
structure  of  the  Puget  Sound  Naval  Shipyard  for  NOHIMS  with  the  assistance  of 
Todd  Merrill  from  the  University  of  Washington  and  Michael  Jackson,  another 
industrial  hygienist.  NOHIMS  hardware  and  software  installation  in  Bremerton 
was  accomplished  by  William  Pugh,  Donald  Beck,  and  Michael  W.  Congleton,  Ph.D., 
M.D. 

Initially  the  industrial  hygienists  entered  their  own  survey  data  into 
NOHIMS,  in  particular  Larry  Kalcso  and  Pete  Howard.  Survey  data  currently  are 
input  to  NOHIMS  by  a  data  entry  clerk.  Roger  Beckett,  Head  of  the  Industrial 
Hygiene  Division,  located  at  the  Puget  Sound  Naval  Shipyard,  under  the  Naval 
Hospital,  Bremerton,  Washington  provided  administrative  support  for  the 
introduction  of  NOHIMS  at  the  second  test  site,  allowing  staff  the  time  needed 
to  initialize  NOHIMS  and  learn  how  to  use  the  system. 

As  the  industrial  component  of  NOHIMS  became  operational  in  Bremerton, 
Michael  Jackson  assumed  the  role  of  NOHIMS  system  manager,  a  responsibility  that 
now  consumes  50  percent  of  his  time.  Other  NOHIMS  users  spend  ten  to  20  percent 
of  their  time  interacting  with  the  system.  Since  NOHIMS  was  introduced  at 
Bremerton,  Michael  Jackson  has  been  involved  in  all  aspects  of  system  start-up 
and  maintenance  including  the  hardware  configuration  and  set  up,  installation  of 
the  operating  system,  daily  management  and  operation  of  the  NOHIMS  software  for 
the  industrial  component,  system  back-up,  troubleshooting,  and  training  of  in- 
house  staff. 


Problems  Encountered  During  the  Implementation  of  NOHIMS 

Thirteen  NOHIMS  users  consisting  of  six  medical  care  providers,  five 
industrial  hygienists,  and  the  two  system  managers  were  asked  what  problems  were 
encountered  during  the  implementation  of  NOHIMS  from  their  individual 
perspectives.  Table  74  presents  the  problems  they  reported  in  response  to  this 
question.  Only  four  problems  were  mentioned  by  more  than  one  respondent  and 
these  four  were  noted  by  only  two  interviewees  each.  These  four  problems  were 
lack  of  user  training,  time  delays  in  installing  hardware  and  telephone  lines, 
initial  software  bugs,  and  initial  shortage  of  data  entry  personnel.  A  medical 
care  provider  identified  problems  with  insufficient  resources  to  allocate  to  the 
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TABLE  74 

Description  of  Problems  Encountered 
During  the  Implementation  of  NOHIMS 
(Number  who  mentioned  problem;  multiple  answers  allowed) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

System 

Managers 

TOTAL 

%  of 

Total  Who 
Answered 

Lack  of  user  training 

0 

2 

0 

2 

22 

Time  delays  in  installing 
hardware  and  telephone 
lines 

0 

0 

2 

2 

22 

Initial  software  bugs 

0 

0 

2 

2 

22 

Initial  shortage  of 
data  entry  personnel 

1 

1 

0 

2 

22 

Insufficient  resources 
to  allocate  to 
implementat ion 

1 

0 

0 

1 

11 

Insufficient  personnel/ 
staffing 

1 

0 

0 

1 

11 

Patient  resistance  to 
filling  out  NOHIMS  forms 

1 

0 

0 

1 

11 

Occupational  and  medical 
history  forms  too  long 

1 

0 

0 

1 

11 

Frustrated  with  increased 
paperwork  at  first 

1 

0 

0 

1 

11 

Personnel  Extract  File  not 
accurate  and/or  current 

0 

1 

0 

1 

11 

Data  entry  backlog  for 
industrial  hygiene 
survey  data 

0 

1 

0 

1 

11 

Initially  no  standardized 
industrial  hygiene  survey 
form 

0 

1 

0 

1 

11 

Interface  with  medical 
care  providers 

0 

1 

0 

1 

11 

No  documentation 
initially  for  the 
industrial  component 

0 

1 

0 

1 

11 

(Continued ) 


Table  74  (CONT.) 

Description  of  Problems  Encountered 
During  the  Implementation  of  NOHIMS 
(Number  who  mentioned  problem;  multiple  answers  allowed) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

System 

Managers 

TOTAL 

%  of 

Total  Who 
Answered 

Industrial  hygienists 
not  exposed  to 
computers  before 

0 

1 

0 

1 

11 

Unstable  work  force 

0 

0 

1 

1 

11 

Initial  hardware  failures 

0 

0 

1 

1 

11 

Indecision  as  to  what 
information  was  needed 

0 

0 

1 

1 

11 

Pressure  to  get  NOHIMS 

operational  prematurely  0  0  1  1  11 


implementation  process  and  insufficient  personnel  or  staff.  Another  medical 
care  provider  expressed  frustration  with  increased  paperwork  at  first.  A  third 
medical  care  provider  felt  that  the  experimental  occupational  and  medical 
history  forms  were  too  long  and  reported  patient  resistance  to  filling  out  the 
new  forms  required  by  NOHIMS. 

The  industrial  hygienists  reported  a  variety  of  problems.  In  San  Diego,  an 
industrial  hygienist  expressed  concern  that  the  Personnel  Extract  File  (PEF)  was 
not  accurate  and/or  current,  leading  to  confusion  about  what  workers  were  in 
which  shops.  Other  problems  mentioned  by  a  San  Diego  industrial  hygienist  were 
that  initially  there  was  no  standardized  industrial  hygiene  survey  form  and  that 
there  was  a  data  entry  backlog  for  survey  data.  One  industrial  hygienist  felt 
that  there  was  a  problem  in  the  beginning  concerning  the  interface  between 
industrial  hygienists  and  medical  care  providers.  Problems  mentioned  by  an 
industrial  hygienist  in  Bremerton  were  lack  of  documentation  initially  for  the 
industrial  component  and  that  they  had  not  been  exposed  to  computers  before. 

Additional  implementation  problems  noted  by  one  of  the  system  managers  were 
initial  hardware  failures,  an  unstable  work  force,  indecision  or  ambivalence  on 
the  part  of  users  as  to  what  information  they  needed  (particularly  in  the  forms 
design  process),  and  pressure  to  bring  NOHIMS  to  an  operational  status 
prematurely.  The  system  manager  in  San  Diego  observed  that  NOHIMS  was  treated 
as  a  production  system  while  it  was  still  under  development. 

The  thirteen  NOHIMS  users  were  also  asked  to  comment  on  how  these  problems 
during  the  implementation  process  were  resolved  or  handled.  The  majority  of  the 
problems  encountered  in  the  implementation  of  NOHIMS  worked  themselves  out 
naturally  as  time  evolved.  Six  of  the  problems  encountered  during 
implementation  are  still  problems.  These  are  lack  of  user  training, 
insufficient  personnel/staffing,  lengthy  occupational  and  medical  history  forms, 
inaccurate  Personnel  Extract  File  data,  data  entry  backlog  for  industrial 
hygiene  survey  data,  and  an  unstable  work  force.  In  addition,  one  medical  care 
provider  commented  that  she  was  annoyed  at  first  with  the  repetitious  paperwork 
but  then  realized  it  was  necessary  to  capture  the  required  information  for  data 
entry.  An  industrial  hygienist  felt  that  there  had  been  a  step-by-step 
resolution  of  the  problems  in  an  evolutionary  process,  much  like  problem  solving 
by  trial  and  error.  Also  a  plan  to  cross-train  secretaries  to  do  data  entry 
should  help  ease  the  survey  data  entry  backlog.  The  system  manager  in  Bremerton 
felt  that  any  problems  encountered  were  normal  problems  to  be  expected  during 
implementation  of  a  test  site,  all  of  which  were  resolved. 

Effect  of  NOHIMS  Installation  on  Staff  Morale 

The  thirteen  users  were  also  asked  if  staff  morale  had  been  affected  by  the 
installation  of  NOHIMS,  whether  this  effect  was  a  positive  or  negative  one,  and 
if  the  effect  was  temporary.  Table  75  summarizes  their  responses  to  this  multi¬ 
part  question.  Of  the  nine  individuals  responding,  78  percent  felt  that  the 
effect  on  staff  morale  initially  was  negative  and  22  percent  thought  the  effect 
was  positive  initially.  The  negative  responses  were  generally  a  result  of  the 
problems  encountered  during  implementation  and  because  of  the  increased  workload 
generated  by  the  advent  of  NOHIMS.  The  medical  care  provider  who  thought  that 
the  initial  effect  was  positive  based  her  response  on  her  perception  that 
"things  are  clearer  now,"  and  that  she  was  legally  covered  by  NOHIMS  back-up  as 


TABLE  75 

How  Staff  Morale  Was  Affected  by  the  Installation  of  NOHIMS 
(Number  who  mentioned  effect) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

System 

Managers 

TOTAL 

%  of 

Total  Who 
Answered 

The  initial  effect  was 

Negative 

3 

3 

I 

7 

78 

Positive 

1 

0 

1 

2 

22 

TOTAL  WHO  ANSWERED 

4 

3 

2 

9 

100 

No  Comment 

2 

2 

0 

4 

TOTAL  INTERVIEWED 

6 

5 

2 

13 

The  final  effect  was 

Positive 

4 

3 

2 

9 

100 

TOTAL  WHO  ANSWERED 

4 

3 

2 

9 

100 

No  Comment 

2 

2 

0 

4 

TOTAL  INTERVIEWED 

6 

5 

2 

13 
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to  why  she  was  doing  what.  A  medical  care  provider  who  felt  that  the  initial 
effect  on  staff  morale  was  negative  explained  his  response  this  way.  "The 
medical  ancillaries  have  so  much  more  work  to  do,  however,  people  like  to  be  a 
part  of  interesting  new  things."  One  hundred  percent  of  the  NOHIMS  users 
responding  to  this  multi-part  question  thought  that  the  final  effect  of  NOHIMS 
installation  on  staff  morale  was  positive,  some  even  added  that  the  effect  was 
very  positive.  Reasons  given  for  this  long-term  positive  effect  on  staff  morale 
were  the  availability  of  more  concise  survey  data  collection  forms  liked  by  both 
industrial  hygienists  and  data  entry  personnel  and  that  "data  now  exist  in  black 
and  white."  An  industrial  hygienist  in  Bremerton  commented  that  NOHIMS  has 
forced  them  to  get  out  to  all  workplaces  to  collect  base-line  survey  data  and 
has  forced  compliance  with  some  requirements  of  the  5100. 23B  NAVOP  instructions. 
As  a  result,  they  are  better  meeting  the  requirements  of  their  job.  The  medical 
care  providers  felt  that  NOHIMS  has  generally  ha  '  a  positive  long-term  effect 
because  medical  surveillance  is  more  appropriate  y;  less  unnecessary  tests  and 
examinations  are  being  performed  and  fewer  peoj  \re  slipping  through  the 
cracks  [of  medical  surveillance]." 

Operational  Procedures  at  Test  Sites 

When  NOHIMS  was  implemented  at  the  North  Island  NARF  in  San  Diego, 
California  it  was  a  completely  new  data  collection  and  processing  system  that 
replaced  an  essentially  manual  system.  The  Systematic  Arrangement  For 
Examinations  (SAFE)  program  was  in  place  at  North  Island,  but  it  used  very 
limited  automation.  Thus,  the  advent  of  NOHIMS  introduced  automation  of 
occupational  health  information  on  a  scale  never  before  experienced  at  the 
Industrial  Hygiene  Division  of  the  Occupational  and  Preventive  Medicine 
Department  or  the  Occupational  Health  Unit  (OHU).  Implemention  of  the 
industrial  component  of  NOHIMS  at  the  Industrial  Hygiene  Division,  Puget  Sound 
Naval  Shipyard  in  Bremerton,  Washington  also  introduced  a  completely  new  data 
collection  and  processing  system  into  that  Navy  industrial  environment, 
replacing  a  previous  manual  system.  This  subsection  describes  the  operational 
procedures  that  have  evolved  for  data  collection,  data  entry,  data  retrieval, 
and  report  generation/utilization  as  well  as  problems  encountered  in  the  day-to- 
day  operation  of  NOHIMS  at  these  two  test  sites. 

Current  Data  Collection  Procedures  for  NOHIMS 

In  San  Diego,  patient  data  for  the  medical  component  of  NOHIMS  are 
collected  using  a  set  of  standard  forms  developed  specifically  for  the  pilot 
test  site.  A  Patient  Registration  form  that  captures  basic  demographic  data 
necessary  for  occupational  health  care  is  filled  out  by  the  patient  the  first 
time  the  patient  is  examined  at  the  OHU.  The  patient  also  fills  out  the  first 
page  of  the  Physical  Exam  Data  Sheet  (PEDS)  encounter  form;  this  page  collects 
encounter-specific  administrative  data  and  is  completed  each  time  a  patient  has 
a  physical  examination.  An  Occupational  Health  Technician  completes  the  rest  of 
the  PEDS  form  which  provides  data  on  job  certification,  hazardous  agent 
surveillance,  protective  equipment,  laboratory  tests,  radiology,  pulmonary 
function  tests,  electrocardiograms,  audiometry,  and  eye  examination.  The 
Physical  Examination  Findings  (PEX)  form  is  completed  by  the  physician  and 
includes  vital  signs,  a  review  of  systems,  a  problem  list,  and  disposition.  The 
Navy  Asbestos  Medical  Surveillance  Program  form  (6260/5)  is  used  by  the 


physician  to  record  patient  data  collected  specifically  for  the  Navy  Asbestos 
Medical  Surveillance  Program.  Two  additional  forms  were  developed  to  collect 
occupational  history  and  medical  history  data.  When  these  experimental  forms 
were  tested  at  the  Occupational  Health  Unit,  they  took  too  long  to  complete. 
Consequently,  they  are  not  in  current  use.  In  most  cases  laboratory  test 
results  are  collected  using  the  standard  Navy  laboratory  chits,  including  the 
Hearing  Conservation  Program  forms  (DD  2215  and  DD  2216).  A  results  form  for 
the  electrocardiogram  is  completed  by  the  physician.  Pulmonary  function  test 
results  are  obtained  directly  from  the  patient's  medical  record.  At  data  entry, 
physicians  verify  the  medical  data  on  the  data  collection  forms  only  if  there 
are  any  ambiguities,  questions,  or  omissions. 

At  North  Island,  survey  data  for  the  industrial  component  of  NOHIMS  are 
collected  by  industrial  hygienists  and  workplace  monitors  using  the  standard 
industrial  hygiene  survey  data  collection  forms  developed  specifically  for 
NOHIMS.  These  include  the  Industrial  Hygiene  Survey  Form,  the  Occupational 
Hazard  Data  Sheet,  and  the  Materials  Inventory.  These  survey  forms  have  been 
well  received  by  other  industrial  hygienists  and  are  in  general  use  in  the  San 
Diego  medical  region.  The  survey  data  collected  by  the  workplace  monitors  are 
verified  by  the  industrial  hygienists.  A  peer  review  process  is  used  to  review 
the  survey  data  collected  by  the  industrial  hygienists  themselves.  About  three 
surveys  were  being  conducted  per  month  at  the  time  of  our  interviews.  Each 
workplace  is  supposed  to  be  surveyed  annually.  However,  because  of  a  lack  of 
industrial  hygienists,  they  cannot  meet  this  schedule  and  are  surveying  every 
two  to  three  years  instead.  The  other  source  of  data  for  the  industrial 
component  of  NOHIMS  in  San  Diego  is  the  Personnel  Extract  File  (PEF)  that 
provides  workplace  information  on  a  monthly  basis  for  workers  at  the  North 
Island  NARF. 

At  Bremerton,  Washington,  survey  data  for  the  industrial  component  of 
NOHIMS  are  now  collected  by  industrial  hygiene  personnel  using  the  NOHIMS 
industrial  hygiene  survey  forms.  Base-line  survey  data  were  collected  in  the 
field  with  a  portable  Epson  microcomputer  using  a  standardized  data  collection 
format.  This  survey  information  then  was  passed  over  to  the  Plessey 
microcomputer  for  permanent  NOHIMS  storage.  Printouts  of  survey  data  from  the 
Plessey  are  used  to  conduct  survey  updates  as  required  and  annual  walk-through 
inspections.  Technical  supervisors  and/or  the  head  industrial  hygienist  review 
and  verify  all  survey  data  before  they  are  entered  in  NOHIMS.  No  data  on  the 
workplace  location  of  workers  at  the  Puget  Sound  Naval  Shipyard  are  yet 
available  for  entry  into  NOHIMS. 


Current  Data  Entry  Procedures  for  NOHIMS 

A  full-time  data  entry  clerk  enters  the  medical  data  into  NOHIMS  at  the 
North  Island  Occupational  Health  Unit  in  San  Diego.  There  usually  is  no  backlog 
for  medical  data  entry  unless  there  are  problems  with  the  communication 
lines/equipment  or  NOHIMS  is  experiencing  hardware  downtime.  Data  entry  is  not 
routinely  verified. 

At  the  time  of  our  interviews,  survey  data  collected  at  North  Island  were 
entered  into  the  industrial  component  of  NOHIMS  by  one  industrial  hygienist 
(Anne  Burton)  and  by  Naval  Health  Research  Center  personnel  (Diana  Hamilton). 

The  industrial  hygienist  wished  that  she  had  time  to  do  more  data  entry  because 


she  has  access  to  relevant  reference  material  and  felt  that  she  was  more 
accurate.  The  industrial  hygienist  at  the  NARF  Safety  Office  corroborated  this 
assessment,  noting  that  Anne  Burton  verifies  the  survey  data  as  she  enters  it. 
At  the  time  of  our  interviews,  the  data  entry  backlog  for  survey  data  was 
approximately  one-half  month  of  data  entry  work. 

At  Bremerton,  Washington  there  is  one  data  entry  clerk  who  spends 
approximately  half  of  her  time  entering  survey  data  into  the  industrial 
component  of  NOHIMS.  The  industrial  hygienists  reported  that  there  never  is  a 
data  entry  backlog  because  they  cannot  survey  faster  than  data  entry  is 
accomplished . 


Current  Data  Retrieval  Procedures  for  NOHIMS 


In  San  Diego,  the  data  retrieval  capabilities  of  NOHIMS  are  not  fully 
utilized  because  of  lack  of  time  and  training.  The  data  retrieval  capabilities 
of  the  industrial  component  were  better  understood  at  the  time  of  our  interviews 
than  those  of  the  medical  component.  When  we  asked  who  requests  retrieval  of 
data  from  NOHIMS,  we  were  given  a  variety  of  examples.  Physicians  and  nurses 
request  data  on  individual  exposures  for  unscheduled  patients  and  occasionally 
they  request  survey  data.  At  the  time  of  our  interviews,  the  Patient  Summary 
and  Encounter  Reports  were  not  being  printed  for  scheduled  patients  although 
these  reports  of  the  patient's  electronic  medical  record  could  provide  a  useful 
adjunct  to  the  patient's  paper  chart,  particularly  if  the  paper  chart  is 
misplaced  or  lost.  A  remedy  for  this  situation  would  be  to  automatically  print 
a  Patient  Summary  and  Most  Recent  Encounter  for  each  scheduled  patient  for 
placement  in  the  patient's  paper  chart  and  to  educate  the  care  providers  in  the 
useful  features  of  these  medical  reports. 

Other  examples  of  requests  for  retrieval  of  medical  data  from  NOHIMS  in  San 
Diego  were  telephone  calls  from  division  clerks  to  find  out  the  date  a  patient 
was  seen  and  from  work  supervisors  to  learn  whether  a  worker  had  been  given  a 
particular  test  in  the  last  year.  Work  supervisors  may  also  request  data  for 
personnel  actions  and  environmental  pay  decisions.  Data  are  requested  to  help 
substantiate  or  refute  worker  complaints  and  claims.  The  industrial  hygienists 
request  survey  data,  standards  and  exposure  levels  for  walk-through  inspections, 
and  data  to  support  compliance  with  specific  OSHA  standards  (e.g.,  lead 
surveys).  Management  statistics  have  been  requested  by  NEHC  such  as  the  number 
of  workers  exposed  to  particular  hazardous  substances.  The  industrial  hygienist 
at  the  NARF  Safety  Office  uses  data  retrieved  from  NOHIMS  to  answer  queries  from 
work  center  supervisors  and  others,  to  develop  work  plans  for  the  workplace 
monitors,  and  to  defend  worker  claims.  This  interviewee  would  like  to  see  the 
NARF  safety  specialists  using  NOHIMS  but  he  questioned  who  was  going  to  train 
them.  A  final  example  of  requests  for  retrieval  of  data  from  NOHIMS  came  from 
NHRC  where  epidemiologists  have  requested  special  data  retrieval  to  conduct 
research  studies. 

At  the  North  Island  Occupational  Health  Unit,  requests  by  rare  providers 
for  medical  or  survey  data  are  handled  by  one  of  the  occupational  health 
technicians  who  usually  retrieves  the  desired  information  within  minutes.  How 
long  it  takes  to  obtain  the  requested  information  depends  on  how  busy  the  staff 
is  at  the  moment  of  the  request,  although  most  requests  are  answered  the  same 
day.  More  complex  requests  that  involve  NOHIMS  Report  Generator  runs  in  the 
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medical  component  are  handled  by  NHRC  staff  and  response  time  could  be  as  long 
as  several  days  depending  on  the  NHRC  workload  and  the  complexity  of  the 
request. 

The  industrial  hygienists  in  San  Diego  can  retrieve  most  data  requested  of 
them  within  minutes  to  a  day.  How  long  it  takes  is  more  a  function  of  finding 
the  time  to  do  it.  If  the  request  involves  an  interactive  query  of  the 
industrial  component's  database,  NHRC  staff  typically  set  up  the  query,  with  the 
output  retrieved  by  the  end  of  the  day.  Occasionally  the  data  entry  clerk  for 
the  medical  component  retrieves  requested  data  for  the  industrial  hygienists. 

In  Bremerton,  Washington  any  member  of  the  Industrial  Hygiene  Division  may 
request  retrieval  of  data  from  NOHIMS  and  all  industrial  hygienists  have  access 
to  the  query  mode  where  the  parameters  for  commonly  run  reports  are  saved.  All 
of  the  industrial  hygienists  were  taught  how  to  retrieve  industrial  data  from 
NOHIMS  by  Michael  Jackson,  the  system  manager.  If  an  industrial  hygienist  does 
not  know  how  to  retrieve  desired  data,  he  asks  Mr.  Jackson  for  help.  One 
industrial  hygienist  commented  that  the  query  function  is  an  extremely  useful 
and  easy-to-use  tool  which  he  uses  to  retrieve  all  survey  data  with  one  request 
rather  than  the  slower  method  of  retrieving  desired  data  items  one  by  one.  How 
long  it  takes  to  retrieve  survey  data  depends  on  which  shipyard  zone  the  survey 
falls  in.  According  to  the  NOHIMS  system  manager  in  Bremerton,  the  longest 
search  was  taking  about  15  minutes  at  the  time  of  our  interviews.  Turn-around 
time  for  most  searches  was  normally  fast  enough  for  what  was  being  done. 


Current  Uses  of  Reports  and  Data  Generated  by  NOHIMS 

The  medical  care  providers  in  San  Diego  reported  the  following  uses  of 
reports  and  data  generated  by  NOHIMS:  use  of  the  Individual  Exposure 
Examination  Report  (IEER)  and  sometimes  the  Patient  Data  Sheet  (Patient  Summary) 
or  a  hardcopy  of  a  survey  report  to  provide  health  care;  day-to-day  and  month- 
to-month  epidemiological  analyses;  and  a  way  to  monitor  the  "hot  spots." 

The  following  uses  of  reports  and  data  generated  by  NOHIMS  were  mentioned 
by  industrial  hygienists  in  San  Diego:  workload  scheduling  of  industrial 
hygiene  tasks,  preparation  of  workplace  monitoring  plans  and  sampling  schedules, 
an  inventory  of  shops  in  their  jurisdiction,  printout  of  data  for  a  survey  as  an 
actual  report,  reporting  everyone  exposed  to  hazardous  agent  X,  and  retrieval  of 
data  for  managing  medical  emergencies  such  as  a  spill.  The  industrial 
hygienists  in  Bremerton  also  use  the  data  generated  by  NOHIMS  to  prepare 
workplace  monitoring  plans  for  survey  updates. 

All  of  the  care  providers  with  NOHIMS  experience  agreed  that  the  medical 
data  collection  instruments  developed  for  NOHIMS  exist  in  addition  to  the 
previously  used  forms  or  records.  The  traditional  paper  chart  is  still  the 
basic  medical  record  used  by  care  providers  in  San  Diego.  Two  care  providers 
viewed  the  computer-generated  report  as  existing  in  addition  to  the  paper 
medical  record  (hopefully  temporarily  as  noted  by  one  physician)  while  the 
occupational  health  technician  who  uses  NOHIMS  the  most  felt  that  the  computer- 
generated  report  supports  the  paper  medical  record. 

Since  the  data  collection  forms  were  designed  around  OIIU  procedures,  only 
minor  changes  in  operational  procedures  were  required  by  NOHIMS.  NOHIMS  has 
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necessitated  policy  changes,  however.  Examples  included  different  criteria  for 
determining  who  receives  an  examination  and  different  criteria  for  determining 
what  kinds  of  examinations  and/or  tests  will  be  done. 

All  of  the  industrial  hygienists  in  both  San  Diego  and  Bremerton  agreed 
that  the  standardized  industrial  hygiene  survey  forms  have  replaced  previously 
used  forms  or  records.  One  industrial  hygeinist  noted  that  the  standard  forms 
made  data  collection  more  concise  and  that  not  much  change  in  previous  standard 
operating  procedures  was  required  to  utilize  reports  and  data  generated  by 
NOHIMS.  This  same  interviewee  also  observed  that  NEHC  views  the  survey  data 
collected  with  this  form  as  replacing  OPNAVINST  5100. 23B.  One  of  the  industrial 
hygienists  in  Bremerton  reported  that  a  variance  had  been  obtained  to  substitute 
NOHIMS  computer  output  for  the  required  OPNAV  5100/14  form — the  Workplace 
Monitoring  Plan. 

All  of  the  NOHIMS  users  in  San  Diego  who  responded  to  our  questioning 
agreed  that  NOHIMS  reports  are  being  used  to  identify  workers  requiring  physical 
examinations.  In  Bremerton,  NOHIMS  is  lacking  the  personnel  files  needed  to 
track  workers  as  well  as  the  medical  module.  However,  we  were  told  at  the  time 
of  our  interviews  that  within  the  previous  four  months  it  had  become  possible  to 
make  recommendations  concerning  appropriate  physical  examinations  via  the 
environment-exam  requirement  display. 

When  we  asked  the  medical  care  providers  in  San  Diego  if  NOHIMS  reports 
were  being  used  to  monitor  compliance  with  Navy  standards,  two  interviewees 
responded  "yes"  and  two  other  individuals  responded  "no"  to  this  question.  One 
physician  who  responded  "no"  commented  that  they  were  not  yet  using  the  system 
as  it  was  designed.  The  industrial  hygienists  in  San  Diego  who  responded  to 
this  question  replied  in  the  affirmative.  The  industrial  hygienist  at  the  North 
Island  NARF  cited  the  generation  of  a  "noise  roster"  as  an  example  of  compliance 
with  Navy  standards.  One  industrial  hygienist  and  the  system  manager  in 
Bremerton  unequivocally  agreed  that  NOHIMS  reports  are  being  used  to  monitor 
compliance  with  Navy  standards.  Another  Bremerton  industrial  hygienist  felt 
that  in  a  sense  NOHIMS  reports  were  being  used  to  monitor  compliance  with  Navy 
standards  in  that  deficiencies  are  now  being  identified. 

When  we  asked  interviewees  if  NOHIMS  is  being  used  to  produce  and/or 
collect  data  for  management  reports,  almost  everyone  responding  to  this  question 
replied  "yes."  One  care  provider  thought  that  the  current  use  was  very 
primitive  yet.  One  medical  ancillary  responded  "no"  to  this  question  because 
she  was  unaware  that  NOHIMS  produces  report  generator  runs  that  tally  frequency 
counts  of  data  items  in  the  medical  component's  database  for  inclusion  in  the 
semi-annual  Report  of  Occupational  Health  Services  (NAVMED  6260/1)  prepared  for 
each  Navy  branch  clinic,  with  copies  forwarded  to  BUMED.  One  industrial 
hygienist  in  Bremerton  responded  that  he  did  not  know  if  NOHIMS  is  used  to 
produce/collect  data  for  management  reports. 


Problems  Encountered  in  the  Day-to-Day  Operation  of  NOHIMS 

NOHIMS  users  were  asked  what  problems  they  had  encountered  in  the  day-to- 
day  operations  of  the  system  and  how  these  problems  were  or  are  being  handled  or 
resolved.  Of  the  medical  care  providers  in  San  Diego,  two  physicians  mentioned 
the  duplication  of  paperwork  because  of  the  dual  manual  and  automated  system. 
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One  of  these  physicians  commented  that  as  a  result,  the  occupational  health 
technicians  are  really  overworked.  He  noted  that  it  also  takes  the  physician  a 
little  extra  time  to  fill  out  the  NOHIMS  forms,  but  that  was  considered  to  be  a 
minor  problem.  His  main  concern  was  that  the  OHU  was  not  getting  much  back  yet 
from  NOHIMS  for  all  the  effort  to  collect  the  data.  The  other  physician  agreed 
that  the  input  effort  so  far  has  exceeded  the  output  from  the  system.  He  felt 
that  NOHIMS  could  be  more  trouble  than  it  is  worth.  He  also  expressed  concern 
that  they  cannot  rely  exclusively  on  NOHIMS  because  of  hardware  downtime.  A 
third  physician  also  mentioned  computer  downtime  as  an  operational  problem  along 
with  slowness  in  being  able  to  get  on-line  and  a  data  entry  backlog.  (This  data 
entry  backlog  had  improved  at  the  time  of  our  interviews.)  Two  medical 
ancillaries  mentioned  patient  resistance  to  filling  out  the  NOHIMS  forms  or 
confusion  over  items  on  the  forms  that  had  to  be  clarified  for  them.  One 
physician's  assistant  commented  that  if  patients  can  see  benefit  from  filling 
out  the  forms,  then  they  do  not  complain.  She  again  mentioned  the  problem  of 
tests  being  scheduled  when  the  worker's  measured  exposure  did  not  exceed  the 
Threshold  Limit  Value  (TLV).  This  apparent  discrepancy  occurs  when  Navy  policy 
dictates  that  all  workers  exposed  to  certain  hazardous  agents  are  to  be 
monitored  medically  regardless  of  the  level  of  their  exposure. 

Two  industrial  hygienists  in  San  Diego  mentioned  problems  with  the 
telephone  line  and  slow  system  response  at  times.  One  of  these  individuals 
complained  about  the  long  time  lag  at  North  Island  to  install  a  dedicated 
telephone  line  and  the  need  for  more  dial-up  ports  than  the  single  port 
currently  available  for  getting  on  the  system.  Two  industrial  hygienists  in  San 
Diego  noted  that  there  were  some  program  bugs  or  errors  that  now  seem  to  be 
mostly  resolved.  One  of  these  individuals  reported  that  she  could  not  find  a 
certain  chemical  name  in  NOHIMS.  She  was  advised  to  report  this  problem  to  the 
NOHIMS  system  manager  for  investigation  and  resolution. 

The  NOHIMS  system  manager  in  San  Diego  mentioned  a  number  of  operational 
problems  that  remain  unresolved  because  NOHIMS  is  running  in  an  R&D  environment 
rather  than  on  production  hardware.  The  primary  problem  is  that  the  DEC  PDP 
11/24  at  NHRC  is  being  used  for  other  R&D  projects  in  addition  to  NOHIMS 
development/production  which  slows  down  the  operational  performance  of  NOHIMS. 
There  is  a  lack  of  user  accessibility  to  the  CPU  because  of  a  single  dial-up 
port  and  the  CPU  is  limited  in  capacity.  There  are  still  problems  with 
communication  lines  and  hardware  downtime.  These  problems  are  handled  as  they 
arise . 

The  industrial  hygienists  in  Bremerton  mentioned  two  problems  encountered 
in  the  day-to-day  operations  of  NOHIMS.  One  individual  commented  that  there 
used  to  be  one  problem  a  day  with  the  system  but  that  most  bugs  are  worked  out 
now.  The  other  industrial  hygienist  emphasized  that  he  does  not  know  the  full 
capabilities  of  NOHIMS  because  of  a  lack  of  training. 

The  NOHIMS  system  manager  in  Bremerton  mentioned  the  following  operational 
problems:  lack  of  user  documentation,  the  need  for  the  Material  Inventory 

function,  and  that  the  database  was  not  large  enough  yet.  The  User  s  Guide  for 
the  industrial  component  of  NOHIMS  had  just  been  received  in  the  mail  at  the 
time  of  our  interviews,  and  Donald  Beck  installed  the  Material  Inventory 
function  right  after  our  interviews.  A  higher  level  Navy  manager  at  Bremerton 
told  us  that  the  time  to  do  a  system  back-up  (which  is  done  every  other  Friday 
afternoon)  is  increasing  and  no  one  can  use  NOHIMS  during  this  time. 


Summary 

The  implementation  process  at  the  test  sites  required  the  effort  of  a 
significant  number  of  people  and  other  resources.  The  installation  process  at 
the  San  Diego  test  site  was  more  involved  because  San  Diego  was  the  pilot  test 
site  where  both  the  industrial  and  medical  components  of  NOHIMS  were  developed. 
Only  the  industrial  component  of  NOHIMS  was  implemented  in  Bremerton.  Each 
module  had  been  fully  tested  at  San  Diego  prior  to  implementation  at  Bremerton. 

The  implementation  process  involved  eight  steps.  The  first  step  in  the 
development  was  a  comprehensive  systems  analysis  of  the  record  keeping  and 
reporting  requirements  of  the  NARF.  As  a  result  of  the  systems  analysis,  a 
semi-automated  interim  system  was  implemented  to  test  NOHIMS  design  concepts. 
Functional  specifications  for  a  fully  automated  NOHIMS  were  then  fully 
developed.  Numerous  people  from  the  Naval  Health  Research  Center,  San  Diego, 
California;  the  Occupational  Health  and  Preventive  Medicine  Department,  San 
Diego,  California;  the  Occupational  Health  and  Preventive  Medicine  Department, 
Bremerton,  Washington;  the  Environmental  Health  Service,  Navy  Regional  Medical 
Clinic,  Hawaii;  the  Navy  Environmental  Health  Center,  Norfolk,  Virginia;  the 
NRMC  Branch  Clinic,  NAS,  North  Island,  San  Diego,  California;  and  the  Naval  Air 
Rework  Facility,  North  Island,  San  Diego,  California  were  involved  in  this 
development  process. 

Once  specifications  for  the  system  had  been  determined,  public  domain 
COSTAR  (Computer  STored  Ambulatory  Record)  was  adapted  for  the  medical  component 
of  NOHIMS  and  new  MUMPS  software  was  written  to  implement  the  industrial 
component.  Data  collection  forms  were  designed,  hardware  and  software  were 
installed,  and  documentation  was  written.  (Only  minimal  training  was  provided 
because  training  was  not  included  in  contract  work  statements.)  These  tasks 
were  accomplished  through  the  team  efforts  of  R-K  Research  and  System  Design, 
Malibu,  California;  The  MITRE  Corporation,  McLean,  Virginia;  the  Department  of 
Occupational  and  Preventive  Medicine,  San  Diego,  California;  the  Department  of 
Occupational  and  Preventive  Medicine,  Bremerton,  Washington;  and  the  Naval 
Health  Research  Center,  San  Diego,  California.  The  development  process  was 
overseen  by  the  Naval  Medical  Research  and  Development  Command,  Bethesda, 
Maryland  and  the  Naval  Environmental  Health  Center,  Norfolk,  Virginia. 

The  most  common  problems  encountered  during  the  implementation  of  NOHIMS 
were  lack  of  user  training,  time  delays  in  installing  hardware  and  telephone 
lines,  initial  software  bugs,  and  initial  shortage  of  data  entry  personnel. 

There  was  also  some  initial  resistance  to  increased  paperwork  on  the  part  of 
staff  and  workers.  The  majority  of  the  problems  encountered  during 
implementation  worked  themselves  out  naturally  as  time  evolved. 

Seventy-eight  percent  of  13  system  users  felt  that  the  implementation  of 
NOHIMS  had  a  negative  effect  on  staff  morale  initially.  The  negative  response 
to  NOHIMS  was  generally  a  result  of  problems  encountered  during  implementation 
and  because  of  the  increased  workload  generated  by  the  advent  of  NOHIMS.  All  of 
the  users  thought  that  the  final  effect  of  NOHIMS  on  staff  morale  was  positive 
or  very  positive. 
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NOHIMS  was  a  completely  new  data  collection  and  processing  system  that 
replaced  an  essentially  manual  system  at  both  test  sites.  Very  little  changes 
in  operational  procedures  were  required  by  NOHIMS  at  the  industrial  test  sites. 
While  NOHIMS  did  not  require  drastic  changes  in  operational  procedures  at  the 
medical  test  sites,  clinic  personnel  did  have  to  accustom  themselves  to  new 
policies  such  as  new  criteria  for  determining  when  and  what  kind  of  physical 
examinations  and/or  tests  were  required. 

The  medical  component  of  NOHIMS  introduced  a  variety  of  new  data  collection 
forms.  These  were  the  Patient  Registration  form,  the  Physical  Exam  Data  Sheet, 
the  Physical  Examination  Findings  form,  and  an  Electrocardiogram  Results  form. 
The  system  also  utilizes  data  from  existing  laboratory  chits,  the  Asbestos 
Medical  Surveillance  Program  form  (6260/5),  and  the  Hearing  Conservation  Program 
forms  (DD  2215  and  DD  2216).  Experimental  occupational  history  and  medical 
history  forms  were  also  developed  but  are  not  in  current  use.  The  industrial 
component  requires  the  use  of  three  new  data  collection  forms,  namely,  the 
Industrial  Hygiene  Survey  form,  the  Occupational  Hazard  Data  Sheet,  and  the 
Materials  Inventory  form. 

Currently,  the  San  Diego  test  site  has  a  full-time  data  entry  clerk  who 
enters  data  into  the  medical  component  of  NOHIMS  and  occasionally  retrieves  data 
from  the  system.  The  industrial  hygienists  at  the  OHU  and  NARF  Safety  Office, 
with  support  from  the  Naval  Health  Research  Center,  enter  the  industrial  hygiene 
data.  Bremerton  has  a  data  entry  clerk  who  devotes  half  of  her  time  to  entering 
industrial  survey  data. 

Retrieval  of  medical  data  from  NOHIMS  is  sporadic  and  varied  in  nature. 
Standard  medical  reports  are  not  routinely  produced  for  inclusion  in  the  medical 
record  or  for  use  by  physicians  during  examinations.  The  traditional  paper 
chart  is  still  the  basic  medical  record  used  by  care  providers.  The  industrial 
hygienists  retrieve  data  from  NOHIMS  frequently.  These  data  are  used  to  respond 
to  requests,  plan  workloads  and  surveys,  and  provide  data  for  reports. 

NOHIMS  is  gradually  being  integrated  into  day-to-day  procedures.  NOHIMS  is 
being  used  to  identify  workers  requiring  physical  examinations.  Since  in 
Bremerton  NOHIMS  is  lacking  the  personel  file  needed  to  track  workers,  this  is 
accomplished  by  making  recommendations  concerning  appropriate  physical 
examinations  via  the  environment-exam  requirement  display. 

The  medical  care  providers  had  varying  opinions  on  whether  NOHIMS  was  being 
used  to  monitor  compliance  with  Navy  standards.  The  industrial  hygienists 
generally  agreed  that  NOHIMS  was  now  oeing  used  to  monitor  compliance  with  .iavy 
standards.  Almost  everyone  felt  that  NOHIMS  was  being  utilized  to  produce 
and/or  collect  data  for  management  reports  although  a  few  people  were  unaware 
that  NOHIMS  could  do  this  or  was  doing  it. 

The  medical  care  providers  mentioned  three  problems  encountered  in  day-to- 
day  operation  of  NOHIMS.  One  problem  was  that  NOHIMS  necessitates  much 
duplicacion  in  efforts  because  OHU  staff  are  maintaining  both  NOHIMS  and  the 
previous  manual  system.  Some  interviewees  expressed  frustration  that  they  were 
not  getting  enough  out  of  the  system  for  what  was  being  put  into  it.  Medical 
care  providers  also  complained  of  system  downtime,  although  this  situation  was 
improving.  The  medical  ancillaries  mentioned  patient  resistance  to  or  confusion 
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over  the  data  collection  forms.  Careful  explanation  of  the  purpose  of  NOHIMS 
usually  overcame  these  problems. 

The  industrial  hygienists  in  San  Diego  mentioned  problems  with  telephone 
lines  and  slow  response  time.  Some  program  bugs  or  errors  experienced  by 
industrial  hygienists  at  both  sites  have  been  resolved.  One  industrial 
hygienist  at  Bremerton  mentioned  lack  of  NOHIMS  training  as  a  day-to-day  problem 
of  NOHIMS  operation. 

The  San  Diego  NOHIMS  system  manager  mentioned  several  operational  problems 
that  remain  unresolved  because  NOHIMS  is  running  in  an  R&D  environment  rather 
than  on  production  hardware,  This  situation  contributes  to  slow  response  time 
and  lack  of  system  accessibility,  and  is  compounded  by  problems  with 
communication  lines  and  hardware  downtime.  The  system  manager  at  Bremerton 
mentioned  problems  with  lack  of  user  documentation,  the  need  for  the  Materials 
Inventory  function,  and  that  the  database  is  not  large  enough  yet.  The  first 
two  problems  were  resolved  last  November  when  Bremerton  received  system 
documentation  and  the  Materials  Inventory  function.  As  the  NOHIMS  database 
becomes  larger,  another  day-to-day  problem  at  Bremerton  is  that  users  do  not 
have  access  to  the  system  a  significant  amount  of  time  every  other  Friday  when  a 
system  back-up  is  performed. 


ASSESSMENT  OF  HOW  WELL  NOHIMS  ADAPTED  TO  INFORMATION 
PROCESSING  NEEDS  AT  TEST  SITES 

The  last  three  questions  in  Component  31  of  Appendix  A  were  included  to 
assess  the  adaptability  of  NOHIMS  to  the  information  processing  needs  at  the 
test  sites.  Thirteen  NOHIMS  users  consisting  of  six  medical  care  providers, 
five  industrial  hygienists,  and  the  two  system  managers  were  asked  these  three 
questions. 

In  the  first  question,  the  interviewees  were  asked  how  well  they  feel 
NOHIMS  has  been  integrated  into  the  day-to-day  procedures  of  their  test  site. 
Table  76  summarizes  their  responses  to  this  question.  All  13  NOHIMS  users 
agreed  that  the  system  has  been  integrated  into  the  day-to-day  procedures  of 
their  test  site  very  well  or  somewhat  well,  with  77  percent  choosing  the  rating 
of  very  well.  There  were  some  qualifications,  however.  One  industrial 
hygienist  in  San  Diego  felt  that  as  far  as  NOHIMS  is  being  used  it  has  been 
integrated  very  well,  but  also  it  has  great  potential  for  further  utilization. 
Another  San  Diego  industrial  hygienist  chose  the  very  well  rating,  but  added 
"although  it  needs  polish."  Medical  care  providers  and  industrial  hygienists 
chose  the  very  well  rating  about  equally  often.  Both  system  managers  thought 
that  NOHIMS  has  been  very  well  integrated  into  the  day-to-day  procedures  of 
their  test  site. 

The  second  question  asked  the  13  interviewees  how  well  they  feel  that 
NOHIMS  has  responded  to  the  particular  needs  of  their  test  site.  Their 
responses  to  this  question  are  shown  in  Table  77.  All  12  of  those  who  answered 
this  question  agreed  that  NOHIMS  has  responded  very  well  to  somewhat  well  to  the 
particular  needs  of  their  test  site,  with  50  percent  choosing  the  rating  of  very 
well.  A  number  of  reasons  were  given  why  the  respondents  chose  a  rating  of  less 
than  very  well.  One  medical  care  provider  felt  that  the  NOHIMS  design  was  "all 


TABLE  76 

How  Well  NOHIMS  Has  Been  Integrated  into  the 
Day-to-Day  Procedures  of  the  Test  Sites 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

System 

Managers 

TOTAL 

%  of 
Total 

Interviewed 

Very  well 

4 

4 

2 

10 

77 

Somewhat  well 

2 

1 

0 

3 

23 

Somewhat  poorly 

0 

0 

0 

0 

0 

Very  well 
Pretty  well/Well* 
Somewhat  well 
Somewhat  poorly 
Poorly 

TOTAL  WHO  ANSWERED 
No  Comment 
TOTAL  INTERVIEWED 

*  Category  added  by 


TABLE  77 

How  Well  NOHIMS  Has  Responded  to  the 
Particular  Needs  of  the  Test  Sites 
(Number  who  mentioned  rating) 


Medical 

Care  Industrial  System 

Providers  Hygienists  Managers  TOTAL 


2  3 


6 


1  10  2 

2  1  14 


0  0  0  0 
0  0  0  0 


12 
1 
13 

respondents 


5  5  2 

1  0  0 

6  5  2 


Answered 
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right,"  but  that  the  data  in  the  system  were  not  being  employed.  An  industrial 
hygienist  in  San  Diego  stated  a  reservation  concerning  if  he  would  be  able  to 
extract  information  from  NOHIMS  in  desired  formats.  The  San  Diego  system 
manager  remarked  that  NOHIMS'  response  to  the  particular  needs  of  his  test  site 
could  be  upgraded  to  very  well  by  implementing  system  improvements  and 
enhancements  such  as  improving  system  access  and  response  time.  Other  comments 
of  interest  included  one  medical  care  provider's  observation  that  procedures  are 
more  standardized  which  minimizes  the  judgment  calls  and  legally  this  should  be 

helpful.  An  industrial  hygienist  in  Bremerton  noted  that  NOHIMS  has  "gotten 

them  out  in  the  field  to  collect  data  and  then  to  load  it  into  the  system."  The 
Bremerton  system  manager  felt  that  NOHIMS  has  responded  very  well  to  the 
particular  needs  of  his  test  site  and  is  continually  improving.  There  was  very 

littre  difference  between  medical  care  providers  and  industrial  hygienists  in 

how  these  two  classes  of  NOHIMS  users  responded  to  this  question. 

In  the  third  question,  the  interviewees  were  asked  if  there  were  needs 
specific  to  their  test  site  that  NOHIMS  could  not  meet,  and  if  so,  what  those 
needs  were.  Two  medical  care  providers  did  not  respond  to  this  question  and 
another  medical  care  provider  could  not  think  of  any  needs  that  were  not  being 
met.  The  other  three  medical  care  providers  identified  some  unmet  needs.  One 
physician  noted  that  NOHIMS  has  not  yet  been  implemented  for  clinical  case 
management  f  injury  and  illness  care.  This  enhancement  of  NOHIMS  for  the  OHU 
in  San  Diego  is  under  development  by  NHRC.  This  same  physician  plans  to  design 
and  implement  a  clinical  effects  table  with  some  method  for  indicating  a  high, 
moderate,  minimal,  or  no  effect.  Another  physician  commented  that  he  puts  risk 
factors  on  a  patient's  problem  list  and  suggested  that  common  risks  be  added  to 
the  Physical  Examination  Findings  (PEX)  encounter  form  in  a  "risk  factor 
section"  that  could  be  checked  off.  He  emphasized  the  need  for  accurate 
information  and  noted  that  outcome  analysis  is  not  being  done  yet.  He  also 
mentioned  that  there  is  no  statistical  capability  in  NOHIMS  for  doing  research. 
One  medical  ancillary  called  attention  to  the  problem  of  tracking  no  shows  for 
scheduled  exams.  Workers  who  do  not  show  for  a  scheduled  exam  during  their 
birth  month  need  to  be  flagged  and  rescheduled.  At  present,  no  shows  are 
"falling  through  the  cracks." 


Four  industrial  hygienists  out  of  five  did  not  identify  any  needs  specific 
to  their  test  site  that  NOHIMS  could  not  meet.  One  of  these  individuals 
observed,  however,  that  NOHIMS  has  made  it  possible  to  document  that  he  was  able 
to  meet  his  work  zone  criterion,  a  beneficial  effect  in  his  view.  A  fifth 
industrial  hygienist  noted  a  desire  for  more  query  capability  so  that  she  could 
produce  lists  and  create  different  combinations  of  lists. 

The  NOHIMS  system  manager  in  San  Diego  saw  a  need  for  more  ports  on  the 
hardware  to  provide  greater  accessibility  to  the  system  for  NOHIMS  users  and  a 
need  for  faster  response  time.  The  Bremerton  system  manager  noted  a  need  to 
test  the  multi-agency  definitions  in  NOHIMS  so  that  other  industrial  activities 
could  be  added  to  the  system  other  than  just  the  shipyard. 


All  13  NOHIMS  users  agreed  that  the  system  has  been  integrated  into  the 
day-to-day  procedures  of  their  test  site  very  well  (77%)  or  somewhat  well  (23%). 
Fifty  percent  of  the  respondents  felt  that  NOHIMS  has  responded  very  well  to  the 
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particular  needs  of  their  test  site,  17  percent  thought  pretty  well  or  well,  and 
33  percent  judged  NOHIMS'  response  as  somewhat  well.  The  San  Diego  system 
manager  felt  that  NOHIMS'  response  to  the  particular  needs  of  his  test  site 
could  be  upgraded  to  very  well  by  implementing  system  improvements  and 
enhancements  while  the  Bremerton  system  manager  thought  NOHIMS'  response  to  the 
needs  of  his  test  site  is  continually  improving.  Needs  that  NOHIMS  could  not 
meet  that  were  each  mentioned  by  one  of  the  interviewees  included  the  collection 
of  data  for  injury  and  illness  care  (currently  under  development  by  NHRC),  a 
check  list  for  risk  factors  on  the  PEX  form,  a  statistical  capability  for  doing 
research,  flaeeine  and  rescheduling  of  no  shows  for  scheduled  exams,  mere  query 
capability  in  the  industrial  component,  more  ports  to  provide  San  Diego  users 
greater  access  to  NOHIMS,  a  need  for  faster  response  time,  and  a  need  in 
Bremerton  to  test  multi-agency  definitions  to  permit  other  industrial  activities 
to  be  added  to  NOHIMS  besides  the  shipyard. 


ASSESSMENT  OF  ACCEPTABILITY  OF  NOHIMS 

The  interview  guide  for  assessing  the  acceptability  of  NOHIMS  to  system 
users  contained  16  questions.  The  exact  wording  of  these  questions  may  be  found 
in  Component  32  of  Appendix  A.  Twelve  NOHIMS  users  consisting  of  six  medical 
care  providers  and  six  industrial  hygienists  were  asked  these  16  questions.  The 
NOHIMS  system  manager  in  Bremerton  inadvertently  also  was  asked  these  questions. 
Since  his  comments  were  relevant  and  he  is  also  an  industrial  hygienist,  he  was 
included  with  the  five  other  industrial  hygienists  in  this  analysis. 

In  the  first  question,  the  interviewees  were  asked  in  general  how 
adequately  they  feel  that  NOHIMS  performs  the  functions  that  are  required  in 
their  work.  Table  78  summarizes  their  responses  to  this  question.  All 
respondents  agreed  that  NOHIMS  adequately  or  somewhat  adequately  performs  the 
functions  required  in  their  work,  with  73  percent  choosing  the  rating  of 
adequately.  Industrial  hygienists  rated  NOHIMS  higher  on  this  question  than  the 
medical  care  providers,  which  may  be  a  reflection  of  the  fact  that  the 
industrial  component  has  been  in  routine  use  in  San  Diego  approximately  a  year 
longer  than  the  medical  component  and  possibly  has  been  better  integrated  j.nto 
daily  work  routines. 

In  the  next  question,  interviewees  were  asked  to  rate  how  reliable  they 
feel  that  NOHIMS  is.  All  respondents  felt  that  NOHIMS  is  reliable  or  somewhat 
reliable,  with  70  percent  choosing  the  rating  of  reliable  (see  Table  79).  The 
industrial  hygienists  as  a  group  felt  that  NOHIMS  was  more  reliable  than  the 
medical  care  providers  did.  One  medical  care  provider  who  rated  NOHIMS  as 
somewhat  reliable  again  mentioned  the  need  to  double-check  Threshold  Limit 
Values  (TLVs)  for  the  appropriateness  of  tests  that  were  recommended.  This 
individual  was  unaware  that  Navy  policy  dictates  that  all  workers  exposed  to 
certain  hazardous  agents  are  to  be  monitored  medically  regardless  of  their 
exposure  level.  One  industrial  hygienist  commented  that  NOHIMS  was  reliable 
because  they  have  back-ups  of  their  database. 

All  respondents  to  question  3  felt  that  NOHIMS  is  both  user  friendly  and 
easy  to  operate  (see  Table  80).  Two  medical  care  providers  did  not  answer  this 
question  but  all  industrial  hygienists  did. 


TABLE  78 

Rating  of  How  Adequately  NOHIMS  Performs  the 
Functions  Required  in  the  User’s  Work 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

TOTAL 

%  of 

Total  Who 
Answered 

Adequately 

3 

5 

8 

73 

Somewhat  adequately 

2 

1 

3 

27 

Somewhat  inadequately 

0 

0 

0 

0 

Inadequately 


0 


0 


0 


0 


TABLE  79 

Rating  of  How  Reliable  NOHIMS  Is 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

TOTAL 

%  of 

Total  Who 
Answered 

Reliable 

2 

5 

7 

70 

Somewhat  reliable 

2 

1 

3 

30 

Somewhat  unreliable 

0 

0 

0 

0 

Unreliable 


0 


0 


0 


0 
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TABLE  80 

Rating  of  How  User  Friendly  and  Easy  to  Operate  NOHIMS  Is 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

TOTAL 

%  of 

Total  Who 
Answered 

NOHIMS  is 

4 

6 

10 

100 

NOHIMS  is  somewhat 

0 

0 

0 

0 

NOHIMS  is  somewhat  not 

0 

0 

0 

0 

NOHIMS  is  not 

0 

0 

0 

0 

TOTAL  WHO  ANSWERED 

4 

6 

10 

100 

No  Comment 

2 

0 

2 

TOTAL  INTERVIEWED  6  6  12 
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The  NOHIMS  data  collection  forms  were  rated  equally  acceptable  by  medical 
care  providers  and  industrial  hygienists,  with  83  percent  of  both  groups  rating 
the  forms  as  acceptable  and  17  percent  rating  the  forms  as  somewhat  acceptable 
(see  Table  81).  One  medical  care  provider  thought  that  the  Physical  Examination 
Findings  (PEX)  form  was  the  easiest  to  use  although  filling  out  the  data 
collection  forms  for  NOHIMS  requires  a  duplication  of  effort.  Another  medical 
care  provider  was  not  certain  of  the  length  limits  for  textual  comments  in  the 
patient's  NOHIMS  medical  record.  One  industrial  hygienist  who  thought  the  data 
collection  forms  were  acceptable  observed  that  the  forms  had  the  limitation  of 
an  8-1/2  by  11  inch  sheet  of  paper. 

Only  the  six  medical  care  providers  were  asked  to  rate  the  acceptability  of 
NOHIMS  data  collection  forms  to  the  patient/worker.  Two-thirds  of  the  care 
providers  felt  that  they  were  acceptable  and  one-third  felt  that  they  were 
somewhat  acceptable  (see  Table  82).  One  of  the  medical  care  providers  who  chose 
the  rating  of  somewhat  acceptable  commented  that  patients/workers  are 
overwhelmed,  confused,  and  intimidated  by  the  NOHIMS  forms  and  that  some  time  is 
required  to  allay  their  fears. 

In  Table  83,  the  changes  in  procedures  required  by  NOHIMS  were  rated  as  to 
their  acceptability.  All  of  the  industrial  hygienists  and  two-thirds  of  the 
medical  care  providers  felt  that  the  procedural  changes  were  acceptable.  One 
industrial  hygienist  commented  that  the  procedural  changes  have  moved  in  the 
direction  of  increased  standardization  and  that  the  changes  required  have  been 
beneficial.  Another  industrial  hygienist  felt  that  the  procedural  changes  were 
both  acceptable  and  desirable.  The  two  medical  care  providers  who  rated  the 
required  procedural  changes  as  less  than  acceptable  provided  the  following 
reasons  for  their  rating.  The  need  to  cut  down  on  the  duplication  of  effort 
prompted  one  medical  care  provider's  rating  of  somewhat  acceptable.  The  other 
medical  care  provider  who  chose  the  rating  of  somewhat  acceptable  commented  that 
unfortunately  the  changes  are  really  additions  to  the  procedures. 

All  of  the  respondents  felt  that  NOHIMS  is  an  aid  in  the  provision  of  care 
to  the  patient/worker  (see  Table  84).  There  was  no  difference  between  the 
medical  care  providers  and  industrial  hygienists  in  their  ratings.  One 
industrial  hygienist  in  San  Diego  expressed  a  desire  to  use  NOHIMS  more  than  she 
has  been  doing.  A  Bremerton  industrial  hygienist  noted  that  NOHIMS  allows  much 
better  worker  monitoring. 

Only  the  six  medical  care  providers  were  asked  to  rate  whether  NOHIMS  has 
disrupted  traditional  patterns  of  clinical  thinking  and/or  patient  management. 
One-third  of  the  medical  care  providers  felt  that  NOHIMS  had  not  been  disruptive 
and  two-thirds  felt  that  NOHIMS  had  been  somewhat  disruptive  (see  Table  85). 

The  two  medical  care  providers  who  felt  that  NOHIMS  had  not  been  disruptive 
added  further  comments.  One  physician  thought  NOHIMS  had  enhanced  traditional 
patterns  of  clinical  thinking  and/or  patient  management.  Another  physician 
cautioned  against  relying  on  NOHIMS  without  knowing  the  system's  limitations. 
Three  of  the  four  medical  care  providers  who  chose  the  somewhat  disrupted  rating 
qualified  their  choice  as  follows:  (1)  not  in  a  bad  way,  (2)  only  in  a  positive 
sense,  and  (3)  has  changed  for  the  good. 

The  medical  care  providers  and  industrial  hygienists  were  also  asked  how 
NOHIMS  has  affected  their  workload.  The  ratings  varied  greatly.  Forty-two 
percent  of  the  respondents  felt  that  NOHIMS  lias  significantly  increased  their 
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Rating  of  Acceptability  of  Data  Collection  Forms 
(Number  who  mentioned  rating) 

to  NOHIMS 

Users 

Medical 

Care 

Providers 

Industrial 

Hygienists 

TOTAL 

%  of 
Total 

Interviewed 

Acceptable 

5 

5 

10 

83 

Somewhat  acceptable 

1 

1 

2 

17 

Somewhat  unacceptable 

0 

0 

0 
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Unacceptable 
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0 

0 
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TABLE  82 

Acceptability  of  NOHIMS  Data  Collection  Forms  to  the  Patient/Worker 
According  to  the  Medical  Care  Providers 
(Number  who  mentioned  rating) 


Acceptable 
Somewhat  acceptable 
Somewhat  unacceptable 
Unacceptable 


TOTAL 


%  of 
Total 

Interviewed 


4 


67 


2  33 

0  0 


0 
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TABLE  83 

Rating  of  Acceptability  of  Changes  in  Procedures 
Required  by  NOHIMS 
(Number  who  mentioned  rating) 


Medical 

Care  Industrial 

Providers _ Hygienists 


%  of 
Total 

TOTAL  Interviewed 


Acceptable 
Somewhat  acceptable 
Somewhat  unacceptable 
Unacceptable 


4 

1 

1 

0 


6 

0 

0 

0 


10 

1 

1 

0 


84 

8 

8 

0 


TOTAL  INTERVIEWED 


6 


6 


12 


100 


TABLE  84 

Rating  of  How  Well  NOHIMS  Facilitates  the 
Provision  of  Care  to  the  Patient/Worker 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

TOTAL 

NOHIMS  is  an  aid 

5 

5 

10 

NOHIMS  is 

somewhat  of  an  aid 

0 

0 

0 

NOHIMS  has  no  effect 

0 

0 

0 

NOHIMS  is  somewhat 
of  a  hindrance 

0 

0 

0 

NOHIMS  is  a  hindrance 

0 

0 

0 

TOTAL  WHO  ANSWERED 
No  Comment 
TOTAL  INTERVIEWED 


5 
1 

6 


5 

1 

6 


10 

2 

12 


%  of 

Total  Who 
Answered 

100 

0 

0 

0 

0 

100 
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TABLE  85 

Rating  by  Medical  Care  Providers  Whether  NOHIMS  Has  Disrupted 
Traditional  Patterns  of  Clinical  Thinking  and/or  Patient  Management 

(Number  who  mentioned  rating) 

%  of 
Total 

TOTAL _ Interviewed 

2  33 

4  67 


Not  disrupted 
Somewhat  disrupted 
Significantly  disrupted 


0 


0 


workload,  17  percent  felt  that  their  workload  has  been  somewhat  increased  by 
NOHIMS,  and  25  percent  of  the  respondents  judged  that  while  NOHIMS  has  not 
significantly  increased  or  decreased  their  workload,  it  has  changed  the  nature 
of  their  workload  (see  Table  86).  Of  those  respondents  choosing  the 
significantly  increased  rating,  one  physician  commented  that  it  is  much  harder 
to  do  a  haphazard  or  less  than  complete  job  now.  An  industrial  hygienist  noted 
that  his  workload  has  been  significantly  increased  because  much  more  detailed 
data  are  being  collected  now.  One  industrial  hygienist  who  stated  that  the 
nature  of  her  workload  had  changed  attributed  this  change  to  the  fact  that  she 
was  doing  survey  data  entry  that  she  did  not  think  was  part  of  her  job.  Table 
86  also  shows  that  one  industrial  hygienist  thought  her  workload  had  been 
somewhat  decreased,  and  one  physician  felt  that  there  had  been  no  net  effect  on 
his  workload,  that  is,  he  felt  that  it  took  more  time  to  collect  the  data  but 
the  quality  of  available  data  had  improved. 

Table  87  presents  the  features  selected  by  the  12  NOHIMS  users  that  have 
been  incorporated  into  their  everyday  work  procedures.  Every  one  of  the 
interviewees  reported  that  the  NOHIMS  data  collection  forms  are  now  a  standard 
procedure.  Two-thirds  of  both  medical  care  providers  and  industrial  hygienists 
use  the  on-line  look-up,  Query/Report  module,  and/or  Interactive  Flowcharts. 
One-third  of  NOHIMS  users  generate  reports,  primarily  the  industrial  hygienists. 
Twenty-five  percent  of  the  interviewees  use  displays  or  printouts  of  standard 
reports,  primarly  the  medical  care  providers.  Three  industrial  hygienists  (25% 
of  the  total  interviewed)  indicated  that  they  were  doing  data  entry.  Of  these 
three  individuals,  one  was  in  San  Diego  and  two  were  in  Bremerton. 

The  interviewees  were  next  asked  whether  they  felt  that  NOHIMS'  features 
have  made  their  jobs  easier  or  harder.  Table  88  shows  that  66  percent  of  those 
interviewed  felt  that  these  features  have  made  their  job  much  easier  (41%  of  the 
total  interviewed)  or  somewhat  easier  (25%).  Four  out  of  six  industrial 
hygienists  compared  to  one  out  of  six  medical  care  providers  chose  the  rating  of 
much  easier.  Two  medical  care  providers  (17%)  felt  that  NOHIMS'  features  had 
had  no  effect  on  the  difficulty  of  their  job.  Another  17  percent  (one  medical 
care  provider  and  one  industrial  hygienist)  thought  that  their  job  was  somewhat 
harder  as  a  result  of  NOHIMS'  features.  The  industrial  hygienist  thought  his 
job  was  somewhat  harder  because  it  is  more  time-consuming  to  gather 
comprehensive  data. 

With  regard  to  productivity,  82  percent  of  the  respondents  felt  that 
NOHIMS'  features  have  made  them  more  productive  (see  Table  89).  All  of  the 
industrial  hygienists  chose  this  rating  while  only  60  percent  of  the  medical 
care  providers  who  responded  chose  this  rating.  Two  of  the  three  medical  care 
providers  (medical  ancillaries)  who  chose  the  rating  of  more  productive  gave 
these  reasons  for  their  choice,  cne  thought  she  was  more  productive  in  the 
sense  that  she  has  more  to  work  with  (e.g.,  recent  reports)  and  knows  exposure 
levels.  The  other  thought  she  was  more  productive  because  she  can  see  more 
patients  in  a  day.  Two  other  medical  care  providers  felt  that  they  were  either 
about  as  productive  or  less  productive. 

Sixty-seven  percent  of  the  interviewees  felt  that  they  can  perform  their 
jobs  more  efficiently  and  effectively  because  of  NOHIMS,  with  50  percent  of  the 
medical  care  providers  versus  83  percent  of  the  industrial  hygienists  choosing 
this  rating  (see  Table  90).  Twenty-five  percent  of  the  interviewees  felt  that 
they  were  performing  their  jobs  somewhat  more  efficiently  and  effectively  (two 
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TABLE  86 


Rating  of  How  NOHIMS  Has  Affected  Workload 
(Number  who  mentioned  rating) 

of  Users 

Medical 

Care 

Providers 

Industrial 

Hygienists 

TOTAL 

%  of 
Total 

Interviewed 

Significantly 
increased  workload 

2 

3 

5 

42 

Somewhat 

increased  workload 

2 

0 

2 

17 

Somewhat 

decreased  workload 

0 

1 

1 

8 

Significantly 
decreased  workload 

0 

0 

0 

0 

Changed  nature 
of  workload 

1 

2 

3 

25 

No  effect 
on  workload 

1 

0 

1 

8 

TOTAL  INTERVIEWED 


6 


6 


12 


100 


TABLE  87 

NOHIMS  Features  That  Have  Been  Incorporated 
into  Everyday  Work  Procedures 
(Number  who  mentioned  feature;  multiple  answers  allowed) 


Medical 

Care 

Providers 


Industrial 

Hygienists 


TOTAL 


%  of 
Total 

Interviewed 


Data  collection  forms 

On-line  look-up, 
Query/Report  module, 
Interactive  Flowcharts 

Report  generation 

Display  of 
standard  reports 

Printed  standard  reports 

Data  entry 


TOTAL  INTERVIEWED 


271 


Much  easier 
Somewhat  easier 
No  effect 
Somewhat  harder 


TABLE  88 

Rating  of  Whether  NOHIMS'  Features  Have  Made 
a  User's  Job  Easier  or  Harder 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

TOTAL 

%  of 
Total 

Interviewed 

1 

4 

5 

41 

2 

1 

3 

25 

2 

0 

2 

17 

1 

1 

2 

17 

Much  harder 


0 


0 


0 
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TABLE  89 

Rating  of  Whether  NOHIMS’  Features  Have  Made 
Users  Less  or  More  Productive 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

TOTAL 

%  of 

Total  Who 
Answered 

More  productive 

3 

6 

9 

82 

About  as  productive 

1 

0 

1 

9 

Less  productive 

1 

0 

1 

9 

TOTAL  WHO  ANSWERED 

5 

6 

11 

100 

No  Comment 

1 

0 

1 

TOTAL  INTERVIEWED 

6 

6 

12 

TABLE  90 

Rating  of  How  Efficiently  and  Effectively  System  Users 
Can  Perform  Their  Jobs  Because  of  NOHIMS 
(Number  who  mentioned  rating) 


Medical 

Care  Industrial 

Providers _ Hygienists _ TOTAL 


Tot 

Interviewed 


More  efficiently 
and  effectively 

Somewhat  more 
efficiently 
and  effectively 

To  the  same  level 
of  efficiency  and 
effectiveness 

Somewhat  less 
efficiently 
and  effectively 


67 


25 


0 


Less  efficiently 
and  effectively 


1 


0 
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medical  care  providers  and  one  industrial  hygienist)  while  one  medical  care 
provider  thought  he  was  performing  his  job  less  efficiently  and  effectively 
right  now.  He  expressed  concern  that  the  staff  was  oriented  toward  getting 
caught  up  on  NOHIMS  data  collection  at  the  expense  of  other  surveillance 
functions.  This  physician  was  newly  arrived  at  the  Occupational  Health  Unit 
(OHU)  and  perhaps  did  not  have  a  full  grasp  of  the  system's  potential  for  aiding 
in  surveillance  functions. 

All  of  the  respondents  felt  that  in  general  people  have  adapted  well  (55% 
of  the  respondents)  or  somewhat  well  (45%)  to  NOHIMS  (see  Table  91).  There  was 
very  little  difference  in  the  way  that  the  medical  care  providers  and  industrial 
hygienists  made  this  rating.  Two  of  the  three  medical  care  providers  who  chose 
the  rating  of  somewhat  well  offered  some  comments.  One  physician  thought  that 
the  OHU  needs  someone  to  organize  the  NOHIMS  application.  Another  medical  care 
provider  observed  that  both  providers  and  workers  seem  somewhat  befuddled  by 
NOHIMS. 

As  a  final  question,  the  interviewees  were  asked  to  make  an  overall  rating 
of  NOHIMS'  acceptability.  Table  92  shows  that  all  of  the  interviewees  felt  that 
NOHIMS  overall  is  acceptable  (83%)  or  somewhat  acceptable  (17%).  There  was  no 
difference  between  the  medical  care  providers'  and  industrial  hygienists' 
ratings  in  response  to  this  question.  The  physician  who  chose  the  rating  of 
somewhat  acceptable  thought  NOHIMS  has  a  ways  to  go  yet  to  be  acceptable.  A 
physician  who  chose  the  rating  of  acceptable  also  commented  that  NOHIMS  must 
have  further  development,  and  if  this  were  done,  then  the  system  would  be  very 
valuable  to  take  care  of  large  groups  of  workers  systematically. 


Summary 

Twelve  NOHIMS  users  (six  medical  care  providers  and  six  industrial 
hygienists)  assessed  the  acceptability  of  NOHIMS  along  a  number  of  different 
dimensions.  All  respondents  agreed  that  NOHIMS  adequately  (73%  of  total 
respondents)  or  somewhat  adequately  (27%)  performs  the  functions  required  in 
their  work.  Likewise,  all  respondents  felt  that  NOHIMS  is  reliable  (70%)  or 
somewhat  reliable  (30%).  The  industrial  hygienists  felt  that  NOHIMS  was  more 
reliable  than  the  medical  care  providers  did.  All  respondents  (100%)  felt  that 
NOHIMS  is  both  user  friendly  and  easy  to  operate. 

NOHIMS  data  collection  forms  were  rated  as  acceptable  to  NOHIMS  users  by  83 
percent  of  the  interviewees  and  as  somewhat  acceptable  by  17  percent  of  the 
interviewees.  There  was  no  difference  between  the  response  of  the  medical  care 
providers  and  the  industrial  hygienists  for  this  rating.  Only  the  medical  care 
providers  were  asked  to  rate  the  acceptability  of  NOHIMS  data  collection  forms 
to  the  patient/worker.  Two-thirds  of  the  medical  care  providers  felt  they  were 
acceptable  and  one-third  felt  they  were  somewhat  acceptable. 

All  of  the  industrial  hygienists  and  two-thirds  of  the  medical  care 
providers  felt  that  the  changes  in  procedures  required  by  NOHIMS  were 
acceptable.  All  of  the  respondents  (100%)  thought  that  NOHIMS  is  an  aid  in  the 
provision  of  care  to  the  patient/worker.  Only  the  medical  care  providers  were 
asked  to  rate  whether  NOHIMS  has  disrupted  traditional  patterns  of  clinical 
thinking  and/or  patient  management.  One-third  felt  that  NOHIMS  had  not  been 
disruptive  and  two-thirds  felt  that  NOHIMS  had  been  somewhat  disruptive. 


TABLE  91 

Assessment  of  How  Well  People  Have 
Adapted  to  NOHIMS 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

TOTAL 

%  of 

Total  Who 
Answered 

Well 

3 

3 

6 

55 

Somewhat  well 

3 

2 

5 

45 

Somewhat  poorly 

0 

0 

0 

0 

Poorly 

0 

0 

0 

0 

TOTAL  WHO  ANSWERED 

6 

5 

11 

100 

No  Comment 

0 

1 

1 

TOTAL  INTERVIEWED 


6 


6 


12 


TABLE  92 

Overall  Rating  of  NOHIMS'  Acceptability 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

TOTAL 

Acceptable 

5 

5 

10 

Somewhat  acceptable 

1 

1 

2 

Somewhat  unacceptable 

0 

0 

0 

Unacceptable 

0 

0 

0 

interviewed 


TOTAL  INTERVIEWED 


6 


6 


2 


However,  most  of  the  medical  care  providers  felt  that  the  disruption  in  patterns 
of  clinical  thinking  and/or  patient  management,  if  any,  had  been  beneficial.  Of 
the  12  interviewees,  42  percent  felt  that  NOHIMS  has  significantly  increased 
their  workload,  17  percent  felt  their  workload  was  somewhat  increased,  and  25 
percent  thought  that  NOHIMS  had  changed  the  nature  of  their  workload.  In 
addition,  one  respondent  thought  her  workload  had  been  somewhat  decreased  and 
another  respondent  felt  that  there  had  been  no  net  effect  on  his  workload. 

With  regard  to  NOHIMS  features  that  have  been  incorporated  into  everyday 
work  procedures,  every  one  of  the  interviewees  reported  that  NOHIMS  data 
collection  forms  are  now  a  standard  procedure.  Two-thirds  of  both  medical  care 
providers  and  industrial  hygienists  use  the  on-line  look-up,  Query/Report 
module,  and/or  Interactive  Flowcharts.  One-third  of  NOHIMS  users  generate 
reports,  primarily  industrial  hygienists.  One-fourth  of  the  interviewees  use 
displays  or  printouts  of  standard  reports,  primarily  medical  care  providers,  and 
one-fourth  of  the  interviewees,  all  industrial  hygienists,  were  doing  data 
entry.  Sixty-six  percent  of  those  interviewed  felt  that  these  features  have 
made  their  job  much  easier  (41%)  or  somewhat  easier  (25%).  A  much  higher 
percentage  of  the  industrial  hygienists  than  the  medical  care  providers  chose 
the  rating  of  much  easier.  Eighty-two  percent  of  the  respondents  felt  that 
NOHIMS'  features  have  made  them  more  productive.  All  of  the  industrial 
hygienists  chose  this  rating  while  only  half  of  the  medical  care  providers  did. 

Ninety-two  percent  of  the  interviewees  felt  that  they  can  perform  their 
jobs  more  efficiently  and  effectively  because  of  NOHIMS  (67%)  or  somewhat  more 
efficiently  and  effectively  (25%).  The  industrial  hygienists  gave  NOHIMS  a 
higher  rating  than  the  medical  care  providers  on  how  efficiently  and  effectively 
they  can  perform  their  jobs.  All  of  the  respondents  felt  that  in  general  people 
have  adapted  well  (55%)  or  somewhat  well  (45%)  to  NOHIMS.  All  of  the 
interviewees  felt  that  NOHIMS  overall  is  acceptable  (83%)  or  somewhat  acceptable 
(17%). 


ASSESSMENT  OF  TRANSFERABILITY  OF  NOHIMS 
TO  OTHER  NAVY  INDUSTRIAL  SITES 

The  interview  guide  for  assessing  the  transferability  of  NOHIMS  to  other 
Navy  industrial  sites  contained  six  questions.  The  exact  wording  of  these 
questions  may  be  found  in  Component  33  of  Appendix  A.  The  questions  covered  the 
suitability  of  NOHIMS  to  the  information  processing  needs  of  other  industrial 
sites,  an  assessment  of  the  adequacy  of  the  flexibility  and  adaptabi 1 i ty  of 
NOHIMS,  areas  in  which  NOHIMS  needs  to  be  more  flexible,  an  assessment  of  the 
ease  of  transfer  of  NOHIMS  to  other  Navy  industrial  sites,  specific  problems  the 
interviewees  foresee  in  transferring  NOHIMS  to  other  industrial  sites,  and  an 
assessment  of  what  the  acceptability  of  NOHIMS  among  users  at  other  Navy 
industrial  sites  will  be. 

Iwenty-three  individuals  were  asked  these  questions — three  NIIRC  NOHIMS 
developers,  seven  higher  level  managers,  six  medical  care  providers,  five 
industrial  hygienists,  and  the  two  NOHIMS  system  managers.  Although  the  NOHIMS 
system  manager  in  San  Diego  was  also  one  of  the  NIIRC  NOHIMS  developers,  he  is 
included  in  this  analysis  as  a  NOHIMS  system  manager  because  that  has  been  his 
more  important  role.  In  the  succeeding  discussion,  the  responses  of  the  NIIRC 
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NOHIMS  developers  and  higher  level  managers  are  presented  first  followed  by 
those  of  the  medical  care  providers,  industrial < hygienists,  and  NOHIMS  system 
managers. 


NHRC  NOHIMS  Developers  and  Higher  Level  Managers 

In  the  first  question,  the  NHRC  NOHIMS  developers  and  higher  level  managers 
were  asked  to  assess  the  suitability  of  NOHIMS  to  the  information  processing 
needs  of  other  Navy  industrial  sites.  All  ten  interviewees  thought  that  NOHIMS 
was  suitable  to  some  degree,  with  60  percent  choosing  the  rating  of  very 
suitable,  20  percent  choosing  suitable,  and  20  percent  choosing  somewhat 
suitable  (see  Table  93).  Six  of  the  seven  higher  level  managers  thought  NOHIMS 
was  very  suitable  to  the  information  processing  needs  of  other  Navy  industrial 
sites  whereas  none  of  the  NHRC  NOHIMS  developers  chose  the  very  suitable  rating, 
perhaps  because  the  developers  had  a  better  appreciation  of  the  work  required  to 
customize  NOHIMS  for  other  sites. 

All  of  the  NHRC  NOHIMS  developers  and  higher  level  managers  agreed  that 
NOHIMS  is  adequately  or  somewhat  adequately  flexible  and  adaptable,  with  80 
percent  choosing  the  adequately  flexible  and  adaptable  rating  (see  Table  94). 

All  of  the  developers  and  five  of  the  seven  higher  level  managers  thought  that 
NOHIMS  was  adequately  flexible  and  adaptable. 

The  NHRC  NOHIMS  developers  and  higher  level  managers  next  were  asked  to 
report  any  areas  in  which  NOHIMS  needs  to  be  more  flexible  and  adaptable.  Table 
95  contains  a  summary  of  the  areas  mentioned.  Only  one  area  was  mentioned  by 
more  than  one  respondent,  namely,  addition  of  Material  Safety  Data  Sheet 
information,  considered  desirable  by  two  higher  level  managers.  Other  areas 
mentioned  by  one  of  the  higher  level  managers  were  inclusion  of  illness/in jury 
data  in  NOHIMS  (being  implemented  by  NHRC),  addition  of  a  word  processing 
capability,  addition  of  a  statistical  package,  and  training  in  system  usage. 

One  higher  level  manager  thought  that  there  were  no  areas  in  which  NOHIMS  needs 
to  be  more  flexible  and  adaptable.  Two  of  the  NHRC  NOHIMS  developers  had  no 
comments  on  this  question.  The  third  developer  mentioned  a  need  for  an  ability 
to  re-assign  groups  of  workers  to  new  workplaces  rather  than  just  by 
individuals. 

On  the  question  of  the  ease  of  transfer  of  NOHIMS  to  other  Navy  industrial 
sites,  the  interviewees  were  divided  in  their  ratings.  Ten  percent  felt  that 
the  transfer  process  would  be  difficult,  40  percent  felt  it  would  be  somewhat 
difficult,  30  percent  felt  it  would  be  somewhat  easy,  and  20  percent  felt  the 
transfer  process  would  be  easy  (see  Table  96).  The  managers  tended  to  feel  that 
the  transfer  process  will  be  more  difficult  than  the  developers  did. 

The  NHRC  NOHIMS  developers  and  higher  level  managers  next  were  asked  what 
specific  problems  they  foresaw  in  transferring  NOHIMS  to  other  Navy  industrial 
sites.  Table  97  enumerates  the  problems  that  were  mentioned.  The  most 
frequently  mentioned  problem  was  committing  billets  to  operate  and  manage 
NOHIMS,  cited  by  40  percent  of  the  interviewees,  all  four  of  whom  were  higher 
(  level  managers.  The  problem  mentioned  next  most  frequently  by  three 

|  interviewees  (30%)  was  tracking  worker  personnel.  Three  problems  were  each 

i  mentioned  by  two  of  the  interviewees  (20%) — coordinating  fiscal  and  personnel 

•  resources  with  the  arrival  of  NOHIMS,  dedication/cooperation  of  NOHIMS 
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TABLE  93 

Rating  of  the  Suitability  of  NOHIMS  to  the  Information 
Processing  Needs  of  Other  Navy  Industrial  Sites 
by  NHRC  NOHIMS  Developers  and  Higher  Level  Managers 
(Number  who  mentioned  rating) 


NHRC 

NOHIMS 

Developers 

Higher  Level 
Managers 

TOTAL 

%  of 
Total 

Interviewed 

Very  suitable 

0 

6 

6 

60 

Suitable* 

1 

1 

2 

20 

Somewhat  suitable 

2 

0 

2 

20 

Somewhat  unsuitable 

0 

0 

0 

0 

Very  unsuitable 


0 


0 


0 


0 


TABLE  94 

Rating  of  NOHIMS'  Flexibility  and  Adaptability 
by  NHRC  NOHIMS  Developers  and  Higher  Level  Manager 
(Number  who  mentioned  rating) 

NHRC 

NOHIMS  Higher  Level 

Developers _ Managers _ TOTAL 


Adequately  flexible 

and  adaptable  3  58 


Somewhat  adequately 

flexible  and  adaptable  0 

Somewhat  inadequately 
flexible  and  adaptable  0 

Inadequately  flexible 

and  adaptable  0 


2  2 

0  0 

0  0 


TOTAL  INTERVIEWED 


3 


S 


I 

I 
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TABLE  95 

Areas  in  Which  NOHIMS  Needs  To  Be  More 
Flexible  and  Adaptable  According  to 


NHRC  NOHIMS  Developers  and  Higher  Level  Managers 
(Number  who  mentioned  area;  multiple  answers  allowed) 

NHRC 

NOHIMS 

Developers 

Higher  Level 
Managers 

TOTAL 

%  of 

Total  Who 
Answered 

Addition  of  Material 
Safety  Data  Sheet 
information 

0 

2 

2 

29 

Ability  to  re-assign 
groups  of  workers  to 
new  workplaces  rather 
than  just  individuals 

1 

0 

1 

14 

Inclusion  of  injury/ 
illness  data  in  NOHIMS 

0 

1 

1 

14 

Addition  of  a  word 
processing  capability 

0 

1 

1 

14 

Addition  of  a 
statistical  package 

0 

1 

1 

14 

Training  in 
system  usage 

0 

1 

1 

14 

None 


0 


1 


1 


14 


TABLE  96 

Rating  of  the  Ease  of  Transfer  of  NOHIMS 
to  Other  Navy  Industrial  Sites 
by  NHRC  NOHIMS  Developers  and  Higher  Level  Managers 
(Number  who  mentioned  rating) 


NHRC 

NOHIMS 

Developers 


Higher  Level 
Managers 


TOTAL 


%  of 
Total 

Interviewed 


Difficult 

0 

1 

1 

10 

Somewhat  difficult 

1 

3 

4 

40 

Somewhat  easy 

2 

1 

3 

30 

Easy 

0 

2 

2 

20 

TABLE  97 

Problems  Foreseen  by  NHRC  NOHIMS  Developers  and  Higher  Level  Managers 
in  Transferring  NOHIMS  to  Other  Navy  Industrial  Sites 
(Number  who  mentioned  problem;  multiple  answers  allowed) 


NHRC 

NOHIMS 

Developers 

Higher  Level 
Managers 

TOTAL 

%  of 
Total 

Interviewed 

Committing  billets  to 
operate  and  manage  NOHIMS 

0 

4 

4 

40 

Tracking  worker  personnel 

1 

2 

3 

30 

Coordinating  fiscal  and 
personnel  resources  with 
arrival  of  NOHIMS 

0 

2 

2 

20 

Dedication/cooperation 
of  NOHIMS  personnel 

1 

1 

2 

20 

Training  staff  to  operate  NOHIMS 

1 

1 

2 

20 

Standardizing  industrial 
hygiene  surveys 

1 

0 

1 

10 

Adapting  to  site  size/ 
number  of  workers  served 

1 

0 

1 

10 

Adapting  to  the  variety  of 
industrial  processes  performed 

1 

0 

1 

10 

False  expectations  for  NOHIMS 

1 

0 

1 

10 

Gaining  cooperation 
from  the  command 

0 

1 

1 

10 

Resistance  to  standardizing 
medical  recording  procedures 

0 

1 

1 

10 

Securing  commitment  to 
an  automated  medical 
information  system 

0 

1 

1 

10 

Initial  loading  of 
personnel  data 

0 

1 

1 

10 

Obtaining  dedicated 
telephone  line(s) 

0 

1 

1 

10 

Allocating  adequate  floor 

space  for  hardware  0  1  1  If) 


?C  "-.TTOWITC  nwvm'B 


ww>  wwm  u  u.wm  n.  w  i>  i .»  j-1 


12 


v. 

a 

.A 

A 

>. 


R 


personnel,  and  training  staff  to  operate  NOHIMS.  All  of  the  other  problems 
listed  in  Table  97  were  mentioned  by  only  one  individual  each.  Problems 
mentioned  by  one  developer  each  were  standardizing  industrial  hygiene  surveys 
(seen  as  a  benefit  by  NEHC),  adapting  to  site  size/number  of  workers  served, 
adapting  to  the  variety  of  industrial  processes  performed,  and  false 
expectations  for  NOHIMS  (in  that  the  system  is  directed  at  meeting  OSHA 
requirements  and  not  at  answering  all  medical  questions).  Problems  mentioned  by 
one  higher  level  manager  each  were  gaining  cooperation  from  the  command, 
resistance  to  standardizing  medical  recording  procedures,  securing  commitment  to 
an  automated  medical  information  system,  loading  personnel  data  initially, 
obtaining  dedicated  telephone  line(s),  and  allocating  adequate  floor  space  for 
hardware. 

The  last  question  asked  of  the  NHRC  NOHIMS  developers  and  higher  level 
managers  dealt  with  the  acceptability  of  NOHIMS  among  users  at  other  Navy 
industrial  sites.  All  ten  interviewees  thought  that  NOHIMS’  acceptability  would 
be  high  to  some  degree,  with  ten  percent  choosing  the  rating  of  very  high,  70 
percent  choosing  high,  and  20  percent  choosing  somewhat  high  (see  Table  98). 

The  developers  generally  rated  NOHIMS1  acceptability  higher  than  the  managers 
did.  The  two  higher  level  managers  who  rated  NOHIMS’  acceptability  as  only 
somewhat  high  offered  reasons  why  they  thought  this  would  be  the  case.  One 
industrial  hygiene  manager  felt  that  NOHIMS  users  will  resist  the  extra 
paperwork  involved  until  system  benefits  are  demonstrated  and  that  NOHIMS’ 
acceptability  will  depend  on  the  manager's  attitude  toward  the  system  and  the 
availability  of  resources.  A  medical  manager  predicted  resistance  only 
initially  followed  by  somewhat  high  or  even  high  acceptance  when  individuals 
really  get  involved  with  using  the  system.  Another  manager,  who  rated  NOHIMS' 
acceptability  as  high,  commented  that  NOHIMS'  acceptability  to  users  may  be 
dependent  on  a  proper  orientation  to  the  need  for  and  importance  of  NOHIMS  and 
that  some  commands  may  be  more  responsive  to  occupational  health  and  safety. 


System  Users  and  NOHIMS  System  Managers 

Table  99  shows  how  suitable  the  medical  care  providers,  industrial 
hygienists,  and  NOHIMS  system  managers  thought  NOHIMS  is  to  the  information 
processing  needs  of  other  Navy  industrial  sites.  All  eleven  respondents  (100%) 
thought  NOHIMS  is  very  suitable.  One  medical  ancillary  observed  that  the 
Occupational  Health  Unit  (OHU)  at  the  Ship  Repair  Facility  on  Guam  where  she  had 
worked  previously  had  identical  needs  to  those  of  the  North  Island  OHU.  One 
industrial  hygienist  in  San  Diego  pointed  out  that  every  industrial  hygienist  in 
the  Southwest  region  is  using  the  standard  NOHIMS  survey  form  and  it  was  an  easy 
switchover.  The  following  types  of  industrial  sites  in  the  Southwest  region  are 
currently  using  this  form:  air  station,  hospital,  submarine  base,  naval 
station,  and  naval  training  center.  An  industrial  hygienist  in  Bremerton 
remarked  that  NOHIMS  "fits  very  comfortably  in  the  shipyard  environment"  and 
that  their  military  industrial  hygienist  uses  NOHIMS  on  ships.  Another 
industrial  hygienist  felt  that  since  NOHIMS  handles  the  North  Island  Naval  Air 
Rework  Facility,  it  also  should  be  able  to  handle  other  more  stable  industrial 
environments. 

As  shown  in  Table  100,  all  eleven  respondents  agreed  that  NOHIMS  is 
adequately  flexible  and  adaptable.  One  industrial  hygienist  in  San  Diego  noted 
that  the  crucial  first  step  to  start  up  the  system  is  obtaining  personnel  data. 
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TABLE  98 

Rating  of  the  Acceptability  of  NOHIMS  Among  Users 
at  Other  Navy  Industrial  Sites 
by  NHRC  NOHIMS  Developers  and  Higher  Level  Managers 
(Number  who  mentioned  rating) 


NHRC 

NOHIMS 

Developers 

Higher  Level 
Managers 

TOTAL 

%  of 
Total 

Interviewed 

Very  high 

1 

0 

1 

10 

High 

2 

5 

7 

70 

Somewhat  high 

0 

2 

2 

20 

Somewhat  low 

0 

0 

0 

0 

Low 


0 


0 


0 


0 


TOTAL  WHO  ANSWERED  4  5  2  11  100 

No  Comment  2002 

TOTAL  INTERVIEWED  6  5  2  13 


TABLE  100 

Rating  of  NOHIMS'  Flexibility  and  Adaptability 
by  Medical  Care  Providers,  Industrial  Hygienists, 
and  NOHIMS  System  Managers 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

System 

Managers 

TOTAL 

%  of 

Total  Who 
Answered 

Adequately  flexible 
and  adaptable 

5 

4 

2 

11 

100 

Somewhat  adequately 
flexible  and  adaptable 

0 

0 

0 

0 

0 

Somewhat  inadequately 
flexible  and  adaptable 

0 

0 

0 

0 

0 

Inadequately  flexible 

and  adaptable  0  0  0  0  0 


The  NOHIMS  system  manager  in  Bremerton  remarked  that  the  adaptability  of  NOHIMS 
improves  as  one  becomes  familiar  with  the  system.  He  noted  that  it  seems  rigid 
at  first,  but  when  one  understands  the  system,  it  is  flexible  and  adaptable. 

In  answer  to  the  question  asking  for  areas  in  which  NOHIMS  needs  to  be  more 
flexible  and  adaptable,  75  percent  of  the  respondents  gave  none  (see  Table  101). 
Both  NOHIMS  system  managers,  three  industrial  hygienists,  and  one  medical  care 
provider  fell  in  this  group  of  respondents.  Two  medical  care  providers  each 
mentioned  one  area  in  which  they  felt  NOh'IMS  needs  to  be  more  flexible  and 
adaptable.  One  physician  expressed  a  desire  for  automatic  transfer  of 
recommended  lab  tests  by  the  industrial  component  to  the  medical  component 
patient  record.  One  medical  ancillary  wanted  direct  access  to  lab  data  without 
having  to  go  through  all  of  the  other  patient  data  (this  individual  had  not  been 
trained  in  the  various  ways  to  retrieve  lab  data  selectively). 

Like  the  NHRC  NOHIMS  developers  and  higher  level  managers,  the  system  users 
and  NOHIMS  system  managers  were  divided  in  their  rating  of  the  ease  of  transfer 
of  NOHIMS  to  other  Navy  industrial  sites.  Ten  percent  felt  that  the  transfer 
process  would  be  difficult,  20  percent  felt  it  would  be  somewhat  difficult,  30 
percent  felt  it  would  be  somewhat  easy,  and  40  percent  felt  the  transfer  process 
would  be  easy  (see  Table  102).  The  NOHIMS  system  managers  generally  thought  the 
transfer  process  would  be  more  difficult  than  the  system  users  did.  One 
industrial  hygienist  in  San  Diego  noted  that  the  transfer  process  will  be 
somewhat  easy  as  long  as  there  is  access  to  personnel  data.  An  industrial 
hygienist  in  Bremerton  thought  the  transfer  process  would  be  easy  because  they 
had  been  able  to  adapt  NOHIMS  to  all  environments  that  exist  in  their 
jurisdiction.  The  NOHIMS  system  manager  in  San  Diego  thought  the  transfer 
process  would  be  difficult  and  entail  a  great  deal  of  work.  The  Bremerton 
system  manager  felt  there  were  bound  to  be  some  problems  introducing  a  new 
product  and  that  users  will  need  to  become  familiar  with  the  system. 

Table  103  lists  the  problems  foreseen  by  the  system  users  and  the  NOHIMS 
system  managers  in  transferring  NOHIMS  to  other  Navy  industrial  sites.  Three 
problems  were  mentioned  by  more  than  one  respondent — obtaining  billets  needed 
(25%),  training  of  NOHIMS  personnel  (25%),  and  initial  resistance  (17%). 
Twenty-five  percent  of  those  who  answered  this  question  foresaw  no  problems. 

All  of  the  other  problems  listed  in  Table  103  were  mentioned  by  only  one 
individual  each.  Problems  mentioned  by  one  medical  care  provider  each  were 
adequate  user  training  manuals,  dedication/cooperation  of  NOHIMS  personnel, 
management  understanding  of  how  to  tailor  NOHIMS  for  local  needs,  securing 
commitment  to  an  automated  medical  information  system,  adaptation  to  different 
regulations/standards  for  each  state,  and  a  need  to  expand  the  job  certification 
list.  A  problem  mentioned  by  one  industrial  hygienist  was  access  to  accurate 
personnel  data.  The  San  Diego  system  manager  foresaw  the  following  problems: 
procuring,  installing,  and  testing  NOHIMS  hardware;  allocating  adequate  floor 
space  for  the  hardware;  modifications  to  NOHIMS  software  for  specific  sites;  and 
adaptation  of  data  collection  forms  and  NOHIMS  documentation.  The  Bremerton 
system  manager  foresaw  a  need  for  some  standardization  of  terminology  when 
NOHIMS  is  transferred  to  other  Navy  industrial  sites. 

All  of  the  system  users  who  responded  to  the  last  question  and  both  NOHIMS 
system  managers  felt  that  the  acceptability  of  NOHIMS  among  users  at  other  Navy 
industrial  sites  would  be  very  high  (70%)  or  high  (30%)  (see  Table  104).  One 
physician  remarked  that  "people  are  screaming  for  it — when,  when,  when?" 
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TABLE  101 

Areas  in  Which  NOHIMS  Needs  To  Be  More 
Flexible  and  Adaptable  According  to 
Medical  Care  Providers,  Industrial  Hygienists, 
and  NOHIMS  System  Managers 

(Number  who  mentioned  area;  multiple  answers  allowed) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

System 

Managers 

TOTAL 

None 

1 

3 

2 

6 

Automatic  transfer  of 
lab  tests  recommended 
by  the  industrial 
component  to  the 
medical  component 
patient  record 

1 

0 

0 

1 

Direct  access  to  lab 
data  without  going 
through  the  other 
patient  data 

1 

0 

0 

1 

TOTAL  WHO  ANSWERED 


3  3 


2  8 


No  Comment 


3 


2  0  5 


TOTAL  INTERVIEWED 


6  5 


2  13 


%  of 

Total  Who 
Answered 


75 


12.5 


12.5 


100 
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TABLE  102 

Rating  of  the  Ease  of  Transfer  of  NOHIMS 
to  Other  Navy  Industrial  Sites 
by  Medical  Care  Providers,  Industrial  Hygienists, 
and  NOHIMS  System  Managers 
(Number  who  mentioned  rating) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

System 

Managers 

TOTAL 

%  of 

Total  Who 
Answered 

Difficult 

0 

0 

1 

1 

10 

Somewhat  difficult 

1 

0 

1 

2 

20 

Somewhat  easy 


30 


TABLE  103 

Problems  Foreseen  by  Medical  Care  Providers, 
Industrial  Hygienists,  and  NOHIMS  System  Managers 
in  Transferring  NOHIMS  to  Other  Navy  Industrial  Sites 
(Number  who  mentioned  problem;  multiple  answers  allowed) 


Medical 

Care 

Providers 

Industr ial 
Hygienists 

System 

Managers 

TOTAL 

%  of 

Total  Who 
Answered 

No  problems  foreseen 

0 

3 

0 

3 

25 

Obtaining  billets 
needed 

3 

0 

0 

3 

25 

Training  of  NOHIMS 
personnel 

2 

0 

1 

3 

25 

Initial  resistance 

1 

1 

0 

2 

17 

Adequate  user 
training  manuals 

1 

0 

0 

1 

8 

Dedication/ cooperation 
of  NOHIMS  personnel 

1 

0 

0 

1 

8 

Management  understanding 
of  how  to  tailor  NOHIMS 
for  local  needs 

1 

0 

0 

1 

8 

Securing  commitment  to 
an  automated  medical 
information  system 

1 

0 

0 

1 

8 

Adaptation  to  different 
regulations/ standards 
for  each  state 

1 

0 

0 

1 

8 

Need  to  expand  job 
certification  list 

1 

0 

0 

1 

8 

Access  to  accurate 
personnel  data 

0 

] 

0 

1 

8 

Procuring,  installing, 
and  testing  hardware 

0 

0 

] 

1 

8 

A1 locating 
adequate  floor 
space  for  hardware 

0 

0 

1 

1 

8 

(Cont i nued ) 
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TABLE  103  (CONT.) 

Problems  Foreseen  by  Medical  Care  Providers, 
Industrial  Hygienists,  and  NOHIMS  System  Managers 
in  Transferring  NOHIMS  to  Other  Navy  Industrial  Sites 
(Number  who  mentioned  problem;  multiple  answers  allowed) 


Medical  %  of 

Care  Industrial  System  Total  Who 


Providers 


>ienists  Managers 


TOTAL 


Answered 


Modifications  to 
NOHIMS  software  for 

specific  sites  00118 


Adaptation  of  data 
collection  forms  and 

NOHIMS  documentation  00118 


Need  for  standardized 

terminology  00  118 


TOTAL  WHO  ANSWERED  6  4  2  12  100 

No  Comment  0101 

TOTAL  INTERVIEWED  6  5  2  13 
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TABLE  104 

Rating  of  the  Acceptability  of  NOHIMS  Among  Users 
at  Other  Navy  Industrial  Sites 
by  Medical  Care  Providers,  Industrial  Hygienists, 
and  NOHIMS  System  Managers 
(Number  who  mentioned  rating) 


Very  high 


Somewhat  high 


Somewhat  low 


Very  low 


TOTAL  WHO  ANSWERED 


No  Comment 


TOTAL  INTERVIEWED 


Medical 

Care 


Industrial  System 


Providers  Hygienists  Managers 


TOTAL 


%  of 

Total  Who 
Answered 


Another  care  provider  thought  that  "people  will  look  to  NOHIMS  as  a  relief." 

One  industrial  hygienist  in  San  Diego  predicted  some  resistance  at  first  but 
very  high  acceptance  once  they  have  used  NOHIMS.  One  industrial  hygienist  in 
Bremerton  felt  that  once  users  became  accustomed  to  NOHIMS,  they  would  be 
extremely  pleased  with  the  system.  Another  Bremerton  industrial  hygienist 
commented  that  at  first  there  will  be  a  great  deal  of  work  to  enter  the  required 
information  to  initialize  NOHIMS,  but  in  the  long  run  the  system  will  be  viewed 
as  helpful.  The  San  Diego  system  manager  expected  the  acceptability  of  NOHIMS 
among  users  at  other  Navy  industrial  sites  to  start  out  somewhat  low  initially 
but  to  move  up  to  very  high.  The  Bremerton  system  manager  thought  that  NOHMIS' 
acceptability  among  users  would  be  very  high  when  they  became  familiar  with  the 
system. 


Summary 

Twenty-three  individuals  were  asked  to  assess  the  transferability  of  NOHIMS 
to  other  Navy  industrial  sites.  Six  of  the  seven  higher  level  managers  thought 
NOHIMS  was  very  suitable  to  the  information  processing  needs  of  other  Navy 
industrial  sites  whereas  the  three  NHRC  NOHIMS  developers  felt  that  NOHIMS  was 
suitable  or  somewhat  suitable.  All  of  the  nine  NOHIMS  users  who  responded  and 
the  two  NOHIMS  system  managers  thought  that  NOHIMS  was  very  suitable  to  the 
information  processing  needs  of  other  Navy  industrial  sites. 

NOHIMS  was  considered  to  be  adequately  flexible  and  adaptable  by  all  of  the 
NHRC  NOHIMS  developers,  both  NOHIMS  system  managers,  all  of  the  NOHIMS  users  who 
responded,  and  five  of  the  seven  higher  level  managers.  The  other  two  higher 
level  managers  thought  that  NOHIMS  was  somewhat  adequately  flexible  and 
adaptable.  Areas  mentioned  in  which  an  interviewee  felt  that  NOHIMS  needs  to  be 
more  flexible  and  adaptable  included  addition  of  Material  Safety  Data  Sheet 
information  (mentioned  by  two  interviewees),  inclusion  of  illness/in jury  data  in 
NOHIMS  (being  implemented  by  NHRC),  addition  of  a  word  processing  capability  and 
a  statistical  package,  training  in  system  usage,  ability  to  re-assign  groups  of 
workers  to  new  workplaces  rather  than  just  by  individuals,  and  automatic 
transfer  of  lab  tests  recommended  by  the  industrial  component  to  the  medical 
component  patient  record.  Seven  of  the  15  respondents  to  this  question  (47%) 
thought  that  there  were  no  areas  in  which  NOHIMS  needs  to  be  more  flexible  and 
adaptable. 

The  interviewees  were  divided  in  their  ratings  of  the  ease  of  transfer  of 
NOHIMS  to  other  Navy  industrial  sites.  Overall,  ten  percent  felt  that  the 
transfer  process  would  be  difficult,  30  percent  felt  it  would  be  somewhat 
difficult,  30  percent  felt  it  would  be  somewhat  easy,  and  30  percent  felt  the 
transfer  process  would  be  easy.  The  NOHIMS  system  managers  as  a  group  thought 
the  transfer  of  NOHIMS  to  other  Navy  industrial  sites  would  be  the  most 
difficult  followed  by  the  higher  level  managers,  NHRC  NOHIMS  developers,  medical 
care  providers,  and  lastly  the  industrial  hygienists  who  thought  the  transfer 
process  would  be  the  easiest. 

A  variety  of  problems  were  foreseen  in  transferring  NOHIMS  to  other  Navy 
industrial  sites.  Overall,  the  most  commonly  foreseen  problem  (mentioned  by 
four  higher  level  managers  and  three  medical  care  providers)  was  obtaining/ 
committing  billets  to  operate  and  manage  NOHIMS.  Next  most  frequently  cited  as 
a  problem  was  training  staff  to  operate  NOHIMS  (mentioned  by  five  respondents). 
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Problems  mentioned  by  three  respondents  each  were  tracking  worker  personnel 
and  dedication/cooperation  of  NOHIMS  personnel.  Two  respondents  each  mentioned 
coordinating  fiscal  and  personnel  resources  with  the  arrival  of  NOHIMS,  initial 
resistance,  securing  commitment  to  an  automated  medical  information  system,  and 
allocating  adequate  floor  space  for  hardware.  Seventeen  additional  problems 
were  mentioned  by  only  one  respondent  each.  Several  of  these  problems  were 
related  to  ensuring  that  NOHIMS  is  adapted  to  varying  needs  at  new  sites  such  as 
different  regulations  and  programs.  No  problems  were  foreseen  by  three 
respondents. 

All  20  respondents  thought  that  the  acceptability  of  NOHIMS  among  users  at 
other  Navy  industrial  sites  would  be  high  to  some  degree,  with  40  percent 
choosing  the  rating  of  very  high,  50  percent  choosing  high,  and  10  percent 
choosing  somewhat  high.  The  NOHIMS  system  managers  as  a  group  thought  that 
NOHIMS'  acceptability  to  users  would  be  the  highest  followed  by  medical  care 
providers,  industrial  hygienists,  NHRC  NOHIMS  developers,  and  lastly  higher 
level  managers  who  thought  user  acceptability  would  be  the  least  high.  A  number 
of  respondents,  including  the  two  who  gave  NOHIMS  the  lowest  ratings  on 
acceptability,  felt  that  NOHIMS'  acceptability  among  users  would  increase  as 
they  became  familiar  with  the  system. 
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SECTION  VII 

BRIEF  ECONOMIC  ANALYSIS  OF  NOHIMS 


BACKGROUND 

A  comprehensive  economic  analysis  of  the  costs  and  benefits  of  NOHIMS  was 
not  performed  in  this  test  and  evaluation  of  the  system  per  direction  of  our 
sponsor,  the  Naval  Medical  Research  and  Development  Command,  because  a  thorough 
economic  analysis  had  already  been  conducted  by  the  Naval  Medical  Command.  The 
findings  from  their  economic  analysis  are  reported  in  Appendix  D  of  the  NOHIMS 
System  Decision  Paper  (SDP).  The  economic  analysis  concluded  that  continued 
development  of  NOHIMS  would  be  more  cost  effective  than  procurement  of  a 
commercial  occupational  health  information  system  if  at  least  30  systems  were  to 
be  installed  at  Navy  industrial  sites.  It  was  also  concluded  that  procurement 
of  a  commercial  system  would  require  significant  modifications  to  meet  the 
Navy's  requirements,  adding  further  to  the  cost  of  a  commercial  system. 

The  economic  analysis  reported  in  the  SDP  also  included  a  NOHIMS  benefits 
analysis.  Quantifiable  benefits  identified  were  (1)  enhanced  employee 
productivity  due  to  "all  at  once"  examination  scheduling,  (2)  enhanced  cohort 
identification  for  studies  of  occupational  disease,  and  (3)  improved  clerical 
productivity.  Nonquantif iable  benefits  recognized  in  the  SDP  were  (1)  improved 
quality  of  medical  information,  (2)  improved  quality  of  management  information, 
(3)  improved  compliance  with  OSHA  law,  (4)  availability  of  hazardous  materials 
information,  (5)  improved  employee  protection,  and  (6)  reduced  claims 
compensation.  These  then  were  the  benefits  anticipated  to  result  from  NOHIMS  at 
the  time  the  SDP  was  written  in  June  of  1984. 

As  part  of  our  test  and  evaluation  of  NOHIMS,  we  realized  that  we  had  a 
special  opportunity  to  poll  individuals  involved  with  NOHIMS  regarding  their 
perception  of  any  benefits  accruing  from  the  introduction  of  NOHIMS  at  their 
test  site.  These  individuals,  we  reasoned,  could  provide  us  with  assessments  of 
possible  NOHIMS  benefits  that  only  people  exposed  to  the  system  on  a  regular 
basis  would  be  able  to  make.  Consequently,  we  collected  data  on  NOHIMS  benefits 
as  perceived  by  the  only  people  currently  exposed  to  NOHIMS  in  order  to 
complement  the  benefits  anticipated  in  the  SDP.  These  people  included  six 
medical  care  providers,  five  industrial  hygienists,  and  two  test  site 
administrators.  We  also  polled  the  four  NOHIMS  developers  at  the  Naval  Health 
Research  Center  (NHRC)  and  seven  higher  level  Navy  managers  to  determine  the 
benefits  they  perceived  that  had  accrued  as  a  result  of  introducing  NOHIMS  at 
the  two  test  sites. 


ANALYSIS  OF  THE  PERCEIVED  BENEFITS  OF  NOHIMS 

We  compiled  an  extensive  hierarchical  list  of  possible  benefits  that  the 
advent  of  NOHIMS  might  provide  to  the  Navy,  higher  level  Navy  managers,  NOHIMS 
test  site  administrators,  and  the  system  users  in  both  San  Diego,  California  and 
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Bremerton,  Washington.  The  hierarchy  of  potential  benefits  that  we  generated  is 
shown  below. 

•  Increased  quality  of  care  provided  to  the  worker/patient  through 

fewer  unnecessary  tests  and  ancillary  services 

fewer  unnecessary  examinations/visits 

appropriateness  of  tests  performed 

reduced  waiting  time 

more  accurate  patient  medical  record 

timely  and  perpetual  access  to  data 

earlier  diagnosis  of  illnesses/conditions 

earlier  notification  of  abnormal  test  results/findings 

base-line  data  on  the  health  of  an  employee 

•  Increased  compliance  with  monitoring  programs 

•  Reduction  in  occupational  exposures  to  hazardous  agents 

•  Improved  workplace  monitoring 

better  identification  of  possible  hazards 
better  identification  of  workers  exposed 

•  Safer  working  conditions 

•  Improved  job  certification  program 

•  Increased  confidence  of  workers 

•  Improved  communication  between  those  concerned  with  the  occupational 
health  of  the  worker 

•  Increased  productivity  of  staf f/clinics 

•  Increased  efficiency  in  the  use  of  resources 

•  Savings  in  manpower 

•  Reduction  in  the  cost  of  providing  services 

•  Improved  planning  and  budgeting 

•  More  accurate  administrative  reports 

•  More  accurate/available  database  for  research  efforts 

Using  this  hierarchical  list  of  potential  benefits,  we  asked  the  NHRC 
NOHIMS  developers,  the  higher  level  Navy  managers,  test  site  administrators,  and 
the  system  users  to  identify  which  benefits  they  perceived  were  a  result  of  the 
introduction  of  NOHIMS  at  the  two  test  sites.  We  also  encouraged  them  to 
mention  any  other  health  care,  monitoring,  and/or  administrative  benefits  that 
they  were  aware  of  which  were  not  on  the  list.  We  then  asked  them  to  select  the 
most  significant  benefit  of  NOHIMS  from  those  they  had  mentioned.  Finally,  we 
asked  them  to  judge  whether  the  costs  of  implementing  and  operating  NOHIMS 
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outweigh  the  benefits  or  vice  versa.  The  exact  wording  of  the  questions  that  we 
used  for  this  portion  of  the  interviews  may  be  found  in  Component  34  of 
Appendix  A.  If  an  interviewee  was  requested  to  answer  the  questions  about 
perceived  benefits  in  two  interviews,  the  answers  were  combined  and  included  in 
only  one  category  of  the  following  tables.  We  based  the  category  on  what  was 
the  interviewee's  main  function  with  NOHIMS.  The  difference  between  higher 
level  managers  and  test  site  administrators,  as  we  defined  them,  is  that  the 
work  location  of  the  test  site  administrators  is  the  test  site  and  they 
presumably  have  more  first-hand  knowledge  and/or  experience  with  NOHIMS. 


NHRC  NOHIMS  Developers  and  Higher  Level  Managers 

At  least  three-quarters  of  the  eleven  NHRC  NOHIMS  developers  and  higher 
level  managers  mentioned  the  three  benefits  of  improved  workplace  monitoring, 
increased  compliance  with  monitoring  programs,  and  more  accurate  administrative 
reports.  Six  additional  benefits  were  mentioned  by  73  percent  of  the 
interviewees  (see  Table  105).  The  other  benefits  on  the  hierarchical  list  were 
all  mentioned  by  several  of  the  developers/managers,  but  to  a  lesser  degree  than 
the  first  nine  benefits.  The  developers/managers  observed  15  other  benefits 
than  the  ones  on  the  hierarchical  list.  Four  other  health  care  benefits 
mentioned  were  the  ability  to  interact  with  the  system  to  retrieve  desired 
information,  double  checks  on  abnormal  lab  tests,  capability  to  avert 
accidents/illnesses  by  observing  trends,  and  educational  benefits  from  use  of 
the  system.  Under  other  monitoring  benefits,  profits  that  were  mentioned 
included  the  industrial  hygiene  monitoring  plan  and  the  value  of  data  being 
readily  available.  Other  administrative  benefits  were  the  ability  to  more 
effectively  manage  the  workplace/employees,  standardization  of  data  and  reports, 
and  that  management  information  falls  out  of  having  a  database.  In  addition, 
six  other  general  benefits  were  mentioned  including  improved  morale  of  people 
who  have  access  to  NOHIMS,  help  in  averting  disasters,  tracking  data  items  in 
large  populations,  improvement  in  the  knowledge  of  the  medical  community, 
information  for  the  clinic  physician  director  showing  where  his  staff  is  being 
overworked,  and  education  in  computer  tools. 

The  benefits  noted  by  the  NHRC  NOHIMS  developers  and  by  the  higher  level 
managers  differed,  but  not  greatly.  All  of  the  developers  mentioned  fewer 
unnecessary  tests  and  ancillary  services,  fewer  unnecessary  examinations/visits, 
and  appropriateness  of  tests  performed  while  less  than  half  of  the  managers 
mentioned  these  three  benefits.  A  much  higher  percentage  of  managers  than 
developers  mentioned  increased  productivity  of  staff /clinics ,  increased 
efficiency  in  the  use  of  resources,  safer  working  conditions,  reduction  in  the 
cost  of  providing  services,  improved  planning  and  budgeting,  and  improved  job 
certification  program.  On  the  average,  both  groups  mentioned  about  the  same 
number  of  benefits  per  respondent.  The  NHRC  NOHIMS  developers  mentioned  16.5 
benefits  per  respondent  and  the  higher  level  managers  mentioned  16.9  benefits 
per  respondent. 

Three  problems  with  how  NOHIMS  is  being  used  that  might  compromise  benefits 
surfaced  in  the  interviews.  One  NOHIMS  developer  expressed  concern  that  spills 
are  not  being  recorded  in  the  industrial  component  of  NOHIMS.  Emergency  events 
of  this  nature  can  be  stored  in  NOHIMS  as  a  type  of  environment  called  an  event. 
Industrial  hygienists  need  to  be  trained  as  to  how  to  use  NOHIMS  in  this  manner. 
One  of  the  managers  noted  a  problem  with  the  count  for  how  many  workers  are 
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TABLE  105 

Perceived  Benefits  of  NOHIMS 

According  to  NHRC  NOHIMS  Developers  and  Higher  Level  Managers 
(Number  who  mentioned  benefit;  multiple  answers  allowed) 


NHRC 

NOHIMS 

Developers 

Higher  Level 
Managers 

TOTAL 

%  of 
Total 

Interviewed 

Improved  workplace 
monitoring 

3 

7 

10 

91 

Increased  compliance  with 
monitoring  programs 

3 

6 

9 

82 

More  accurate 
administrative  reports 

3 

6 

9 

82 

Increased  quality  of 
care  provided  to  the 
worker/ patient 

3 

5 

8 

73 

Timely  and  perpetual 
access  to  data 

4 

4 

8 

73 

Better  identification 
of  possible  hazards 

3 

5 

8 

73 

Better  identification 
of  workers  exposed 

3 

5 

8 

73 

Improved  communication 
between  those  concerned 
with  the  occupational 
health  of  the  worker 

4 

4 

8 

73 

More  accurate/available 
database  for  research 
efforts 

3 

5 

8 

73 

Fewer  unnecessary  tests 
and  ancillary  services 

4 

3 

7 

64 

Fewer  unnecessary 
examinations/ visits 

4 

3 

7 

64 

Appropriateness  of 
tests  performed 

4 

3 

7 

64 

Base-line  data  on  the 
health  of  an  employee 

3 

4 

7 

64 

Reduction  in  occupational 
exposures  to  hazardous 
agents 

3 

4 

7 

64 

(Continued) 


TABLE  105  (CONT.) 


NHRC 

NOHIMS 

Developers 

Higher  Level 
Managers 

TOTAL 

%  of 
Total 

Interviewed 

Increased  confidence 

of  workers 

2 

4 

6 

54 

Increased  productivity 

of  staff/clinics 

1 

5 

6 

54 

Increased  efficiency  in 

the  use  of  resources 

1 

5 

6 

54 

Earlier  diagnosis  of 

illnesses/conditions 

2 

3 

5 

45 

Earlier  notification  of 
abnormal  test  results/ 
findings 

2 

3 

5 

45 

Safer  working  conditions 

1 

4 

5 

45 

Reduction  in  the  cost 

of  providing  services 

1 

4 

5 

45 

Improved  planning  and 

budgeting 

0 

5 

5 

45 

Reduced  waiting  time 

1 

3 

4 

36 

More  accurate  patient 

medical  record 

1 

3 

4 

36 

Savings  in  manpower 

1 

3 

4 

36 

Improved  job 

certification  program 

0 

3 

3 

27 

Other  health  care 

benefits 

2 

2 

4 

36 

Other  monitoring  benefits 

1 

1 

2 

18 

Other  administrative 

benefits 

2 

1 

3 

27 

Other  benefits 

1 

5 

6 

54 

TOTAL  INTERVIEWED  4  7  11  100 

Average  No.  of  Benefits 

Mentioned  per  Respondent  16.5  16.9 
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using  respirators,  which  should  trigger  an  annual  medical  examination.  The 
count  has  been  wrong  because  respirator  data  have  not  been  entered  correctly 
into  NOHIMS.  Follow-up  in  April  1986  found  that  this  problem  had  been  resolved 
satisfactorily.  Another  manager  felt  that  both  medical  care  providers  and 
industrial  hygienists  had  not  been  trained  as  well  as  they  should  be  to  receive 
maximum  benefit  from  use  of  the  system.  NOHIMS  users  agree  that  they  have  not 
received  adequate  training  and  do  not  fully  understand  all  of  the  system 
features  that  could  be  of  benefit  to  them. 

When  we  asked  the  developers/managers  to  select  the  most  significant 
benefit  of  NOHIMS  from  those  they  had  mentioned,  many  of  the  interviewees  could 
not  limit  themselves  to  selecting  just  one  most  significant  benefit.  As  a 
result,  Table  106  reflects  more  than  eleven  choices.  In  fact,  18  benefits  were 
noted  as  most  significant.  Mentioned  most  frequently  (four  times)  as  being  the 
most  significant  benefit  of  NOHIMS  was  increased  quality  of  care  provided  to  the 
worker/patient.  Three  benefits  were  mentioned  next  most  frequently  (two  times 
each)  as  being  the  most  significant,  namely,  better  identification  of 
occupational  hazards  and  as  a  result  decreased  occupational  exposures,  improved 
communication  between  those  concerned  with  the  occupational  health  of  the 
worker,  and  increased  productivity  of  staff/clinics.  All  of  the  other  most 
significant  benefits  included  in  Table  106  were  mentioned  only  once.  Four 
benfits  mentioned  by  developers  but  not  by  managers  were  timely  and  perpetual 
access  to  data,  improved  workplace  monitoring,  giving  workers  the  appropriate 
examinations,  and  the  availability  of  a  database  for  research  and  management 
needs.  Managers  mentioned  five  benefits  that  developers  did  not,  namely, 
increased  productivity  of  staff/clinics,  increased  compliance  with  monitoring 
programs,  use  of  NOHIMS  as  a  management  tool,  averting  disasters  because  of  the 
existence  of  a  database,  and  standardized  operation  of  Occupational  Health 
Units. 

Table  107  shows  how  NHRC  NOHIMS  developers  and  higher  level  managers  rated 
the  costs  versus  benefits  of  implementing  and  operating  NOHIMS.  Because 
interviewees  had  no  real  idea  of  what  NOHIMS  implementation  and  operational 
costs  are  other  than  their  own  involvement  of  time,  their  judgments  are  more 
subjective  than  objective.  One  individual  thought  the  costs  somewhat  exceed  or 
outweigh  the  benefits  thus  far.  Seven  individuals  felt  the  benefits  somewhat  or 
clearly  exceed  or  outweigh  the  costs.  Two-thirds  of  those  who  felt  they  could 
weigh  costs  versus  benefits  thought  that  the  benefits  clearly  exceed  or  outweigh 
the  costs.  One  respondent  thought  NOHIMS  will  be  cost  effective  in  time  and  two 
individuals  felt  they  could  not  make  this  rating.  Of  those  who  did  respond, 
their  additional  comments  provide  some  interesting  insights  into  the  value  that 
higher  level  managers  place  on  NOHIMS  benefits.  One  manager  concluded  that  "the 
cost  of  implementing  and  operating  NOHIMS  was  necessary  to  be  able  to  do  the 
job."  Other  managers  commented  "worth  whatever  it  cost"  and  "money  should  not 
hold  this  thing  back."  One  manager  even  went  as  far  as  to  say  that  he  felt  the 
system  was  shortchanged  in  its  development  and  that  not  enough  resources  had 
been  allocated. 


At  least  three-quarters  of  the  13  system  users  and  test  site  administrators 
mentioned  the  four  benefits  of  improved  workplace  monitoring,  increased 
compliance  with  monitoring  programs,  better  identification  of  possible  hazards, 


TABLE  106 

The  Most  Significant  of  Those  NOHIMS  Benefits 
Mentioned  by  NHRC  NOHIMS  Developers  and  Higher  Level  Managers 
(Number  who  chose  benefit  as  most  significant; 
multiple  answers  allowed) 


NHRC 

NOHIMS 

Developers 

Higher  Level 
Managers 

TOTAL 

%  of 
Total 

Interviewed 

Increased  quality  of 
care  provided  to  the 
worker/ patient 

1 

3 

4 

36 

Better  identification  of 
occupational  hazards  and 
as  a  result,  decreased 
occupational  exposures 

1 

1 

2 

18 

Improved  communication 
between  those  concerned 
with  the  occupational 
health  of  the  worker 

1 

1 

2 

18 

Increased  productivity 
of  staf f/clinics 

0 

2 

2 

18 

Timely  and  perpetual 
access  to  data  for 
everyone 

1 

0 

1 

9 

Increased  compliance  with 
monitoring  programs 

0 

1 

1 

9 

Improved  workplace 
monitoring 

1 

0 

1 

9 

Giving  workers  the 
appropriate  examinations 

1 

0 

1 

9 

Use  of  NOHIMS  as  a 
management  tool 

0 

1 

1 

9 

Database  for  research 
and  management  needs 

1 

0 

1 

9 

Averting  disasters  because 
of  existence  of  database 

0 

1 

1 

9 

Standardized  operation  of 
Occupational  Health  Units 

0 

1 

1 

9 

TOTAL  INTERVIEWED  4  7  11  100 


TABLE  107 

Rating  of  Costs  Versus  Benefits  of  Implementing  and  Operating  NOHIMS 
by  NHRC  NOHIMS  Developers  and  Higher  Level  Managers 
(Number  who  mentioned  rating) 


NHRC 

NOHIMS  Higher  Level 

Developers _ Managers _ TOTAL 


%  of 

Total  Who 
Answered 


The  costs  of 
implementing  and 
operating  NOHIMS 

clearly  exceed  or 


outweigh  the  benefits 

0 

0 

0 

0 

somewhat  exceed  or 
outweigh  the  benefits 

0 

1 

1 

11 

equal  the  benefits 

0 

0 

0 

0 

or  the  benefits 

somewhat  exceed  or 
outweigh  the  costs 

1 

0 

1 

11 

clearly  exceed  or 
outweigh  the  costs 

2 

4 

6 

67 

Will  be  cost  effective* 

0 

1 

1 

11 

TOTAL  WHO  ANSWERED 
No  Comment 
TOTAL  INTERVIEWED 


3 

1 

4 


6 

1 

7 


9 

2 

11 


100 


*  Category  added  by  respondent 


and  more  accurate/available  database  for  research  efforts.  The  first  two 
benefits  mentioned  most  frequently  by  system  users  and  test  site  administrators 
were  also  the  two  benefits  mentioned  most  frequently  by  NHRC  NOHIMS  developers 
and  higher  level  managers.  Five  additional  benefits  were  mentioned  by  more  than 
60  percent  of  the  interviewees  (see  Table  108).  The  other  benefits  on  the 
hierarchical  list  were  all  mentioned  by  some  of  the  system  users  and  test  site 
administrators,  but  to  a  lesser  degree  than  the  first  nine  benefits.  None  of 
the  five  industrial  hygienists  mentioned  the  medical  care  benefits  of 
appropriateness  of  tests  performed,  fewer  unnecessary  tests  and  ancillary 
services,  base-line  data  on  the  health  of  an  employee,  improved  job 
certification  program,  and  earlier  notification  of  abnormal  test 
results/findings,  suggesting  that  they  have  a  narrower  view  of  NOHIMS  benefits. 
The  only  benefit  that  was  not  mentioned  by  medical  care  providers  was  savings  in 
manpower.  Under  Other  benefits,  one  test  site  administrator  mentioned  transfer 
of  information  between  operational  units  and  base  stations. 

The  average  number  of  benefits  mentioned  by  the  test  site  administrators 
was  16.5.  This  average  is  similar  to  the  averages  for  the  NHRC  NOHIMS 
developers  and  the  higher  level  managers.  The  average  number  of  benefits 
mentioned  by  the  medical  care  providers  and  by  the  industrial  hygienists  was 
approximately  11,  another  indication  of  their  possibly  narrower  view  of  the 
benefits  of  NOHIMS. 

Like  the  NHRC  NOHIMS  developers  and  higher  level  managers,  the  system  users 
and  test  site  administrators  had  difficulty  limiting  their  selection  to  just  one 
most  significant  benefit  of  NOHIMS.  Table  109  shows  that  the  13  system  users 
and  test  site  administrators  noted  20  benefits  as  most  significant.  Mentioned 
most  frequently  (two  times  each)  as  being  the  most  significant  benefit  of  NOHIMS 
were  timely  and  perpetual  access  to  data,  better  identification  of  possible 
hazards,  and  more  accurate/available  historical  database.  None  of  the  medical 
care  providers  selected  these  three  benefits  as  most  significant.  Better 
identification  of  occupational  hazards  was  also  mentioned  two  times  by 
developers/managers  as  the  most  significant  benefit  of  NOHIMS.  All  of  the  other 
most  significant  benefits  included  in  Table  109  were  mentioned  only  once. 

Medical  care  providers  tended  to  pick  patient  care  and  surveillance  benefits  as 
most  significant.  Industrial  hygienists  focused  more  on  hazard  identification, 
exposure  monitoring,  and  accessibility  to  an  accurate  historical  database.  Test 
site  administrators  noted  as  most  significant  some  spin-off  benefits  and  a 
benefit  not  previously  mentioned,  namely,  that  with  NOHIMS  patient  examinations 
are  based  on  their  exposure  history  rather  than  on  their  occupation  as  was  done 
in  the  past. 

Table  110  shows  how  system  users  and  test  site  administrators  rated  the 
costs  versus  benefits  of  implementing  and  operating  NOHIMS.  One  medical  care 
provider  thought  the  costs  somewhat  exceed  or  outweigh  the  benefits  now  but  that 
the  potential  is  there  to  reverse  this  picture.  He  offered  this  interesting 
analogy  as  an  explanation  for  his  rating.  "It's  like  building  a  freeway.  There 
is  only  one  lane  open  now.  There's  some  pavement  work  to  do  yet,  and  then  all 
lanes  will  be  open."  A  test  site  administrator  felt  that  the  costs  equal  the 
benefits.  Nine  individuals  or  82  percent  felt  that  the  benefits  somewhat  or 
clearly  exceed  or  outweigh  the  costs,  with  55  percent  choosing  the  clearly 
exceed  or  outweigh  the  costs  rating.  Test  site  administrators  most  strongly 
rated  benefits  over  costs  followed  by  industrial  hygienists,  and  then  medical 


TABLE  108 

Perceived  Benefits  of  NOHIMS  According  to  Medical  Care  Providers, 
Industrial  Hygienists,  and  Test  Site  Administrators 
(Number  who  mentioned  benefit;  multiple  answers  allowed) 

Medical  %  of 

Care  Industrial  Test  Site  Total 

Providers  Hygienists _ Admin . _ TOTAL  Interviewed 


Improved  workplace 
monitoring 

4 

5 

2 

11 

85 

Increased  compliance  with 
monitoring  programs 

5 

4 

1 

10 

77 

Better  identification 
of  possible  hazards 

3 

5 

2 

10 

77 

More  accurate/ 
available  database 
for  research  efforts 

4 

5 

1 

10 

77 

Timely  and  perpetual 
access  to  data 

4 

3 

2 

9 

69 

Better  identification 
of  workers  exposed 

3 

4 

2 

9 

69 

Improved  communication 
between  those  concerned 
with  the  occupational 
health  of  the  worker 

2 

5 

2 

9 

69 

Increased  efficiency  in 
the  use  of  resources 

3 

4 

2 

9 

69 

Increased  productivity 
of  staff/clinics 

3 

3 

2 

8 

62 

Improved  planning 
and  budgeting 

1 

3 

2 

6 

46 

Increased  quality  of 
care  provided  to  the 
worker/patient 

3 

2 

0 

5 

38 

Fewer  unnecessary 
examinations/ visits 

3 

1 

1 

5 

38 

Appropriateness  of 
tests  performed 

4 

0 

1 

5 

38 

(Continued) 
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TABLE  108  (CONT.) 

Perceived  Benefits  of  NOHIMS  According  to  Medical  Care  Providers, 
Industrial  Hygienists,  and  Test  Site  Administrators 
(Number  who  mentioned  benefit;  multiple  answers  allowed) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

Test  Site 
Admin . 

TOTAL 

%  of 
Total 

Interviewed 

More  accurate  patient 

medical  record 

3 

1 

1 

5 

38 

Earlier  diagnosis  of 

illnesses/conditions 

2 

2 

1 

5 

38 

Reduction  in  occupational 
exposures  to  hazardous 
agents 

3 

1 

1 

5 

38 

Savings  in  manpower 

0 

3 

2 

5 

38 

More  accurate 

administrative  reports 

3 

1 

1 

5 

38 

Fewer  unnecessary  tests 

and  ancillary  services 

3 

0 

1 

4 

31 

Safer  working  conditions 

1 

2 

1 

4 

31 

Increased  confidence 

of  workers 

2 

1 

1 

4 

31 

Reduction  in  the  cost 

of  providing  services 

1 

1 

2 

4 

31 

Reduced  waiting  time 

for  workers/patients 

2 

1 

0 

3 

23 

Base-line  data  on  the 

health  of  an  employee 

3 

0 

0 

3 

23 

Improved  job 

certification  program 

2 

0 

1 

3 

23 

Earlier  notification 
of  abnormal  test 
results/f indings 

2 

0 

0 

2 

13 

Other  benefits 

0 

0 

1 

1 

8 

TOTAL  INTERVIEWED  6  5  2  13  100 


Average  No.  of  Benefits 
Mentioned  per  Respondent 
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TABLE  109 

The  Most  Significant  of  Those  NOHIMS  Benefits  Mentioned  by 
Medical  Care  Providers,  Industrial  Hygienists, 
and  Test  Site  Administrators 
(Number  who  chose  benefit  as  most  significant; 
multiple  answers  allowed) 


Medical 

Care 

Providers 

Industrial 

Hygienists 

Test  Site 
Admin. 

TOTAL 

%  of 
Total 

Interviewed 

Timely  and  perpetual 
access  to  data 

0 

1 

1 

2 

15 

Better  identification 
of  possible  hazards 

0 

2 

0 

2 

15 

More  accurate/available 
historical  database 

0 

2 

0 

2 

15 

Increased  quality 
of  care  provided 
to  the  worker/patient 

1 

0 

0 

1 

8 

Improved  workplace 
monitoring 

1 

0 

0 

1 

8 

Better  identification 
of  workers  exposed 

1 

0 

0 

1 

8 

Increased  efficiency 
in  use  of  resources 

0 

1 

0 

1 

8 

Standardization  of 
care  and  monitoring 

1 

0 

0 

1 

8 

Improved  patient 
follow-up/ surveillance 
to  hazards 

1 

0 

0 

I 

8 

Increased  ability  to 
do  monitoring  and 
reduce  exposures 

0 

1 

0 

1 

8 

Industrial  Exposure 
Report 

1 

0 

0 

1 

8 

Reliable  information 
management  system 

1 

0 

0 

1 

8 

(Continued) 
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TABLE  109  (CONT.) 

The  Most  Significant  of  Those  NOHIMS  Benefits  Mentioned  by 
Medical  Care  Providers,  Industrial  Hygienists, 
and  Test  Site  Administrators 
(Number  who  chose  benefit  as  most  significant; 
multiple  answers  allowed) 


Medical 

Care 

Providers 


Industrial 

Hygienists 


Test  Site 
Admin . 


TOTAL 


%  of 
Total 

Interviewed 


Compliance  with 
record  keeping 
requirements 


Testing  by  exposure 
history  rather  than 
by  occupation 


0 


1 


Teaching  new  physicians 

occupational  history  0  0  118 

Data  extraction  0  0  118  •„ 

w 

w 

Transfer  of  information  0  0  118 


TABLE  110 

Rating  of  Costs  Versus  Benefits  of  Implementing  and  Operating  NOHIMS 
by  Medical  Care  Providers,  Industrial  Hygienists, 
and  Test  Site  Administrators 
(Number  who  mentioned  rating) 

Medical  %  of 

Care  Industrial  Test  Site  Total  Who 

Providers  Hygienists _ Admin.  TOTAL  Answered 

The  costs  of 
implementing  and 
operating  NOHIMS 


clearly  exceed 
or  outweigh  the 
benefits  0 

somewhat  exceed 
or  outweigh  the 
benefits  1 

equal  the 

benefits  1 

or  the  benefits 

somewhat  exceed 
or  outweigh  the 
costs  1 

clearly  exceed 
or  outweigh  the 
costs 


0 


0 

0 


2 


0  0  0 

0  1  9 

0  1  9 

0  3  27 


2 


2 


2 


6 


55 


care  providers.  One  medical  care  provider  and  one  industrial  hygienist  felt 
they  could  not  make  this  rating. 


Summary 

Table  111  shows  the  costs  versus  benefits  of  implementing  and  operating 
NOHIMS  ratings  for  all  interviewees  combined.  Eighty  percent  of  all  individuals 
who  made  this  rating  felt  that  the  benefits  of  NOHIMS  exceed  or  outweigh  the 
costs,  with  60  percent  of  those  individuals  making  this  rating  indicating  that 
the  benefits  clearly  exceed  or  outweigh  the  costs.  Three  individuals  (15%) 
thought  that  eventually  the  large  developmental  and  start-up  costs  of  NOHIMS 
would  be  exceeded  by  the  system's  benefits.  These  findings  support  the 
expectation  of  benefits  from  NOHIMS  anticipated  in  the  System  Decision  Paper  of 
June  1984.  What  is  of  particular  interest  is  that  the  benefits  that  were 
anticipated  in  1984  do  not  coincide  exactly  with  the  benefits  perceived  by  the 
developers,  managers,  and  users  of  NOHIMS  at  the  time  of  our  interviews.  For 
example,  we  were  unable  to  document  reduced  claims  compensation  by  NOHIMS  at  the 
time  of  our  interviews  because  this  benefit  accrues  from  the  ongoing 
construction  of  an  accurate  historical  database.  On  the  other  hand,  those 
individuals  knowledgeable  about  NOHIMS  at  the  time  of  our  interviews  identified 
additional  system  benefits  that  had  not  occurred  to  us  when  we  compiled  what  we 
thought  was  a  comprehensive  list  of  possible  NOHTMS  benefits.  The  individuals 
we  interviewed  perceived  many  and  varied  ways  that  NOHIMS  is  benefiting  or  will 
benefit  the  Navy  occupational  health  programs,  corroborating  earlier 
expectations  of  major  benefits  from  NOHIMS. 
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TABLE  111 

Rating  of  Costs  Versus  Benefits  of  Implementing  and  Operating  NOHIMS 

by  All  Individuals  Interviewed 
(Number  who  mentioned  rating) 


The  costs  of 
implementing  and 
operating  NOHIMS 

clearly  exceed  or 
outweigh  the  benefits 


TOTAL 


%  of 

Total  Who 
Answered 


somewhat  exceed  or 
outweigh  the  benefits 

equal  the  benefits 


or  the  benefits 

somewhat  exceed  or 
outweigh  the  costs 

clearly  exceed  or 
outweigh  the  costs 


Will  be  cost  effective* 


TOTAL  WHO  ANSWERED 


No  Comment 


TOTAL  INTERVIEWED 


*  Category  added  by  respondent 


SECTION  VIII 

BRIEF  COMPARISON  OF  NOHIMS  TO  OTHER 
OCCUPATIONAL  HEALTH  INFORMATION  SYSTEMS 


This  section  presents  a  brief  comparison  of  NOHIMS  to  other  occupational 
health  information  systems.  Specifically,  NOHIMS  is  compared  to  government- 
owned  occupational  health  systems,  to  commercially  available  occupational  health 
systems,  and  to  the  interim  Navy  occupational  health  system. 


COMPARISON  OF  NOHIMS  TO  GOVERNMENT-OWNED  OCCUPATIONAL 
HEALTH  INFORMATION  SYSTEMS 

Only  one  of  the  individuals  we  interviewed  was  familiar  enough  with 
government-owned  occupational  health  information  systems  other  than  NOHIMS  to 
make  a  comparison.  This  individual  was  a  higher  level  Navy  manager  from  the 
Navy  Environmental  Health  Center  (NEHC)  where  the  NOHIMS  System  Decision  Paper 
(SDP)  was  prepared  in  June  of  1984.  Alternative  systems  to  NOHIMS  in  the 
government  and  commercial  sectors  were  identified,  described,  and  evaluated  in 
the  SDP.  Five  government-owned  systems  were  included  in  the  SDP,  three  from 
non-DOD  government  agencies  and  two  from  DOD  agencies. 


Non-DOD  Government-Owned  Occupational  Health  Systems 


As  reported  in  the  SDP,  a  Naval  Sea  Systems  Command  (NAVSEA)  occupational 
safety  and  health  (OSH)  working  group  conducted  a  search  for  government-owned 
OSH  systems.  Their  search  revealed  that  the  Federal  Occupational  Safety  and 
Health  Administration  (OSHA)  did  not  have  a  record-keeping  or  reporting  system 
that  could  be  used  by  reporting  agencies.  The  working  group  did  find,  however, 
that  the  Department  of  Transportation,  the  Coast  Guard,  and  the  Environmental 
Protection  Agency  each  had  an  OSH-related  information  system  or  were  in  the 
process  of  investigating  the  development  of  one.  The  National  Aeronautics  and 
Space  Administration  (NASA)  has  also  investigated  the  development  of  an  OSH- 
related  information  system. 


The  Department  of  Transportation  (DOT)  has  an  accident/mishap  central 
reporting  system  (no  compensation  function)  for  personal  injuries  and  property 
damage.  Although  the  system  contains  some  environmental  exposure  elements,  it 
is  basically  a  safety-oriented  system  called  the  Voluntary  Employee  Injury/ 
Illness  Reporting  System  (VEIIRS). 


Coast  Guard  System 


The  Coast  Guard  Repair  Station  in  Philadelphia  is  in  need  of  an  OHS  system 
and  at  the  time  of  the  SDP  had  recently  acquired  contract  services  to  study  the 
problem. 
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Environmental  Protection  Agenc 


The  Environmental  Protection  Agency  (EPA)  has  only  an  Injury  Reporting  and 
Information  System  (IRIS)  operating  to  support  solid  waste  management.  The  EPA 
National  Computer  Center  advised  at  the  time  of  the  SDP  that  software  conversion 
efforts  currently  ongoing  at  their  center  could  make  one  commercial  OSH-oriented 
software  application  available  to  government  users  in  the  immediate  future. 
However,  further  discussion  with  EPA  representatives  revealed  that  the  potential 
application  was  not  currently  in  use  and  had  limited  OSH  functions. 


National  Aeronautics  and  Space  Administration  System 


Not  mentioned  in  the  SDP  was  a  study  in  the  late  1970s  for  the  National 
Aeronautics  and  Space  Administration  (NASA)  of  the  information  requirements  of 
NASA's  safety,  environmental  health,  and  occupational  medicine  programs  leading 
to  requirements  for  a  consolidated  information  system  and  recommendations  for  a 
computerized  information  system  (Whyte,  1978;  OSHA  medical  surveillance 
requirements  and  NIOSH  recommendations  for  employees  exposed  to  toxic  substances 
and  other  work  hazards,  1980).  At  the  time  of  the  SDP,  NASA  had  not  implemented 
an  OSH  system. 


POD  Occupational  Health  Sy stems 


The  NAVSEA  working  group  identified  two  efforts  within  the  DOD  other  than 
NO'ilMS  to  develop  an  OSH  system,  one  in  the  U.S.  Army  and  the  other  in  the  U.S. 
Air  Force. 


U.S.  Army  System 


At  the  time  of  the  SDP,  the  Army  did  not  have  an  OSH  system  but  had 
initiated  system  development  efforts.  Safety  Sciences  of  San  Diego  was 
contracted  by  the  Army  to  develop  the  functional  description  and  basic  program 
logic.  It  was  planned  that  the  Army  OSH  system  would  be  modular ly  designed  and 
deployed . 


U.S.  Air  Force  System 


At  the  time  of  the  SDP,  the  Air  Force  (AF)  Logistic  Command  had  developed  a 
standard  OSH  program  (AF  OSH  STD  161-17),  completed  design  of  an  automated 
system  to  support  their  manual  program,  and  was  currently  awaiting  funds  for 
system  development.  The  AF  system  will  eventually  consist  of  six  modules  with 
interactive  capability:  (1)  Industrial  Hygiene,  (2)  Occupational  Medicine, 

(3)  Manpower/Management ,  (4)  Environmental  Protection,  (5)  Coronary  Artery 
Diseases,  and  (6)  Environment  Resident  Response  (chemicals).  Detailed 
discussion  with  regard  to  proposed  module  functions  revealed  that  the  AF  system 
will  not  contain  all  of  the  OSH  functions  required  by  the  Navy.  The  AF 
anticipates  operation  on  a  distributive  mi crocomputer  configuration;  however, 
system  hardware  evaluations  had  not  been  completed.  The  system  was  targeted  to 
be  operational  in  late  1985,  although  the  AF  was  skeptical  that  funding  would  be 
provided  to  complete  all  six  modules  within  this  time  frame.  The  AF  Depot 


Maintenance  Facilities  are  currently  using  the  Computerized  Occupational  Health 
and  Environment  Surveillance  System  (COHESS)  acquired  from  Diamond  Shamrock 
Corporation .  The  AF  indicated  that  COHESS  is  a  temporary  system  which  has  been 
plagued  with  problems  and  will  be  discarded  when  their  Computerized  Occupational 
Health  Program  (COHP)  becomes  fully  operational  (Computerized  Occupational 
Health  Program  (COHP):  Feasibility  Study,  1982). 


Suitability  of  Government-Owned  Occupational  Health 
Information  Systems  to  Navy  Needs 

It  was  reported  in  the  NOHIMS  SDP  that  while  government-owned  occupational 
safety  and  health  systems  existed,  analysis  revealed  that  these  systems  would 
not  meet  Navy  requirements.  Therefore,  procurement  of  an  existing  government- 
owned  system  was  rejected  as  not  a  reasonable  alternative.  The  lone  interviewee 
familiar  with  these  systems,  a  higher  level  Navy  manager  from  NEHC,  concurred  in 
this  assessment,  adding  further  that  none  of  the  government-owned  OSH  systems 
equals  the  capabilities  of  NOHIMS. 


COMPARISON  OF  NOHIMS  TO  COMMERCIALLY  AVAILABLE 
OCCUPATIONAL  HEALTH  INFORMATION  SYSTEMS 

As  part  of  the  first  phase  of  this  test  and  evaluation,  we  conducted  an 
extensive  search  of  relevant  literature  for  references  to  and  descriptions  of 
commercially  available  occupational  health  information  systems  that  could  be 
compared  to  NOHIMS. 

Commercial  Occupational  Health  Information  Systems 

One  entire  issue  of  the  Journal  of  Occupational  Medicine  (Vol.  24,  Issue 
10,  1982)  was  devoted  to  a  description  of  commercially  used  or  marketed 
occupational  health  information  systems.  The  following  companies  reported  in 
this  journal  using  and/or  marketing  an  occupational  health  information  system: 
Alcoa,  Control  Data  Corporation,  Diamond  Shamrock  Corporation,  DuPont,  Eli 
Lilly,  Exxon,  Ford  Motor  Company,  General  Foods,  IBM,  Monsanto,  New  York 
Telephone  Company,  Shell  Oil,  SmithKline,  Standard  Oil  Company  of  California, 
Standard  Oil  Company  of  Indiana  (AMOCO),  Standard  Oil  Company  of  Ohio  (SOHIO), 
and  the  Upjohn  Company.  Other  commercial  occupational  health  information 
systems  reported  in  the  literature  are  DEChealth  (marketed  by  the  Digital 
Equipment  Corporation)  (Reed  &  Solomon,  1982),  ETHOS  (provided  by  Stewart-Todd 
Associates)  (Stewart,  Allen,  Bilella  &  O'Neill,  1982),  FLOW  GEMINI  (marketed  by 
Flow  General)  (Rappaport,  1983;  Rappaport  &  Steen,  1981),  and  Sunllealth 
(developed  jointly  by  Sun  Information  Services  Corporation  and  the  Sun  Oil 
Company)  (Gavin,  1983). 


Suitability  of  Commercially  Available  Occupational 
Health  Information  Systems  to  Navy  Needs 

Only  two  commercial  occupational  health  information  systems  were  compared 
to  NOHIMS  in  the  economic  analysis  of  the  June  1984  NOHIMS  System  Decision 
Paper  (SDP).  The  two  commercial  systems  considered  to  be  the  most  viable 


alternatives  in  the  SDP  were  DEChealth  and  FLOW  GEMINI.  The  NOHIMS  project 
management  team  determined  that  procurement  of  a  commercial  system  would  require 
significant  modifications  to  meet  the  Navy's  requirements.  It  was  also  noted 
that  no  vendor-supplied  systems  are  operational  in  such  diverse  industrial 
environments  as  exist  in  the  Navy.  The  economic  analysis  concluded  that 
continued  development  of  NOHIMS  would  be  more  cost  effective  than  procurement  of 
a  commercial  occupational  health  information  system  if  at  least  30  systems  were 
to  be  installed  at  Navy  industrial  sites.  In  addition,  the  significant 
modifications  needed  to  meet  the  Navy's  requirements  would  add  further  to  the 
cost  of  a  commercial  system. 

Of  those  individuals  whom  we  interviewed,  only  the  higher  level  Navy 
manager  from  NEHC  was  familiar  enough  with  commercially  available  occupational 
health  information  systems  to  be  able  to  compare  them  to  NOHIMS.  His  assessment 
was  that  none  of  the  commercial  systems  equals  the  capabilities  of  NOHIMS. 


COMPARISON  OF  NOHIMS  TO  THE  INTERIM  NAVY 
OCCUPATIONAL  HEALTH  SYSTEM 

A  semi-automated  interim  Navy  occupational  health  system  preceded  the 
development  of  the  fully  automated  Navy  Occupational  Health  Information 
Management  System  (NOHIMS).  The  interim  system  served  two  important  functions 
(Pugh  &  Beck,  1981).  First,  the  interim  system  was  implemented  to  test  design 
concepts  for  the  fully  automated  NOHIMS.  Second,  the  interim  system  provided 
useful  occupational  health  information  services  that  offered  a  preview  of  the 
expanded  capabilities  which  NOHIMS  was  later  to  deliver. 

Description  of  the  Interim  Navy  Occupational  Health  System 

The  interim  Navy  occupational  health  system  was  developed  and  implemented 
at  the  North  Island  Naval  Air  Rework  Facility  (NARF)  located  at  the  Naval  Air 
Station,  San  Diego.  A  medical  encounter  form  was  designed  and  used  to  capture 
data  needed  for  management  reporting  from  the  dispensary.  Information  collected 
on  this  form  included  visit  type;  injuries,  illnesses,  and  symptoms;  adjunct 
services  provided;  causative  agents  for  occupational  medical  conditions;  and 
initial  and  final  disposition.  Trial  testing  at  the  NARF  dispensary 
demonstrated  that  the  specially  designed  encounter  form  could  be  used  to 
complete  the  NAVMED  6300/1  (Medical  Services  and  Outpatient  Morbidity  Report) 
and  the  NAVMED  6260/1  (Report  of  Occupational  Health  Services)  report  forms. 
Testing  also  showed  that  even  a  manual  tally  of  the  data  recorded  on  the 
encounter  form  was  better  than  the  previous  procedures  for  compiling  the  data 
for  these  reports. 

The  Naval  Health  Research  Center  (NliRC)  staff  trained  personnel  at  the  NARF 
dispensary  in  how  to  properly  fill  out  the  encounter  forms.  1  he  data  collected 
on  the  encounter  forms  were  keypunched  at  NHRC.  These  punched  cards  then  were 
fed  into  a  series  of  computer  programs  written  in  FORTRAN  to  automatically 
compile  the  data  for  the  NAVMED  6300/1  and  NAVMED  6260/1  reports  and  to  print 
the  results  on  a  monthly  basis.  This  monthly  batch  operation  involved  a  series 
of  two  dozen  programs  that  had  to  be  run  in  a  particular  sequence.  The  interim 
system  was  not  an  on-line,  interactive  system  as  NOHIMS  was  later  to  be.  It  was 


dictionary-driven,  limited  in  what  functions  it  could  perform,  and  too  labor 
intensive  for  any  long-term  implementation. 


The  interim  system  also  produced  two  monthly  reports — the  Industrial 
Hygiene  Survey  Report  (IHSR)  and  the  Excessive  Exposure  Report  (EER) — in 
addition  to  the  data  for  the  NAVMED  reports.  Copies  of  these  two  reports  were 
given  to  the  industrial  hygienists,  the  occupational  health  nurse,  and  the 
safety  specialists.  In  order  to  generate  these  reports,  it  was  necessary  to 
have  current  personnel  data  on  all  employees  including  demographic  items,  work 
location,  and  work  type.  At  the  NARF,  most  of  these  data  elements  can  be  found 
in  a  computerized  database  called  the  Personnel  Extract  File  (PEF).  Also 
included  in  the  PEF  for  each  employee  is  a  notation  indicating  whether  a  worker 
is  to  have  a  periodic  physical  examination,  the  month  the  examination  is  to  take 
place,  and  a  set  of  "operational  categories"  which  indicate  the  clinical  tests 
that  should  be  performed.  The  interim  system  relied  on  the  PEF  for  monthly 
updates  of  personnel  data  via  a  magnetic  tape  from  the  NARF.  The  interim  system 
also  included  some  environmental  data  pertaining  to  the  presence  of  hazardous 
materials  in  the  workplace  and  individual  exposures.  These  two  reports  served 
as  reference  material  for  the  industrial  hygienists  and  safety  specialists.  The 
occupational  health  nurse  used  the  IHSR  when  scheduling  patients  for  periodic 
physical  examinations  to  determine  if  any  tests  should  be  performed  other  than 
those  which  reflect  the  job  processes  that  the  employee  engages  in.  The 
occupational  health  nurse  used  the  EER  to  identify  workers  exposed  to  hazardous 
materials,  and  in  the  case  of  serious  exposures,  scheduled  the  employees  for  a 
physical  examination.  The  nurse  also  received  a  copy  of  the  PEF  listing  showing 
all  of  the  employees  due  for  a  physical  examination. 

The  interim  system  was  designed  to  collect  only  the  data  needed  to  produce 
the  four  reports  described  above.  It  was  not  designed  to  be  able  to  retrieve  or 
manipulate  data  stored  in  the  database.  The  interim  system  could  produce  counts 
of  the  number  of  physical  examinations  conducted,  the  number  of  laboratory  tests 
done  by  type  of  test,  and  the  number  of  procedures  performed  by  type  of 
procedure.  However,  any  manipulation  of  the  database  to  retrieve  different 
information  or  information  combined  in  different  ways  required  additional 
programming  and  a  great  deal  of  effort.  Therefore,  that  capability  was  deferred 
to  NOHIMS. 


Suitability  of  the  Interim  Navy  Occupational  Health  System  to  Navy  Needs 

Four  individuals  who  were  involved  with  the  design,  development,  and 
operation  of  the  interim  Navy  occupational  health  system  at  NHRC  were  asked  to 
assess  the  interim  system's  suitability  to  Navy  needs.  The  four  questions  they 
were  asked  may  be  found  in  Component  37b  of  Appendix  A. 

With  regard  to  the  interim  system's  suitability  to  Navy  information 
collection  needs,  the  NHRC  system  developers  felt  that  the  system  was  suitable 
within  the  intended  purpose  of  the  interim  system  but  unsuitable  for  the  long¬ 
term  system  because  data  entry  was  cumbersome  and  the  data  collected  were 
incomplete.  Areas  of  additional  data  collection  needed  in  the  long-term  system 
that  were  mentioned  by  the  NHRC  developers  were  more  medical  encounter  data, 
results  of  lab  tests,  first  aid  information  for  acute  exposures,  hazard 
characteristics,  medical  history,  and  occupational  history. 


The  interim  system  was  regarded  as  suitable  to  Navy  information  retrieval 
needs  for  a  developmental  system  to  test  design  concepts  but  not  for  an  ultimate 
system.  One  NHRC  developer  noted  that  the  interim  system  was  more  suitable  for 
retrieving  occupational  data  than  medical  data  in  that  the  system  could  not 
retrieve  data  for  an  individual  patient.  The  NHRC  developers  mentioned  the  need 
for  a  report  generator  and  a  query  capability  in  the  ultimate  system. 

The  interim  system  was  not  considered  suitable  for  Navy  information 
manipulation  needs  by  the  NHRC  developers  because  there  was  no  way  to  query  the 
database.  The  data  were  there,  but  data  items  were  difficult  to  access  and 
manipulate.  The  NHRC  developers  mentioned  the  need  for  a  way  to  make  ad  hoc 
requests  of  the  database  and  a  statistical  analysis  capability  in  the  ultimate 
system. 

Overall,  the  NHRC  system  developers'  assessment  of  the  adequacy  of  the 
interim  system  for  Navy  information  processing  needs  was  that  it  was  adequate 
for  its  intended  interim  purpose  but  that  it  was  inadequate  as  a  long-term 
operational  system. 


Benefits  of  the  Interim  Navy  Occupational  Health  System 


The  NHRC  system  developers  mentioned  a  number  of  benefits  resulting  from 
the  interim  Navy  occupational  health  system  that  they  regarded  as  most 
significant.  One  developer  mentioned  that  the  monthly  reports  produced  by  the 
interim  system  increased  the  acceptance  of  the  NOHIMS  concept.  The 
administrative  reports  produced  by  the  interim  system  were  more  accurate  than 
the  manually  prepared  reports  they  replaced.  Two  developers  noted  the  benefit 
of  considerable  improvement  in  the  appropriateness  of  examinations  and  tests 
performed  resulting  in  increased  efficiency  in  the  use  of  resources. 

An  evaluation  of  the  effectiveness  and  impact  of  the  semi -automated  interim 
system  on  operational  procedures  at  the  NARF  dispensary  was  conducted  by  making 
a  pre-  and  post-comparison  of  medical  surveillance  for  workers  at  the  North 
Island  NARF.  Data  were  collected  and  compiled  for  the  month  prior  to  the 
introduction  of  the  interim  system  (February  1982)  and  for  the  four  months  after 
introduction  of  the  interim  system  (March  through  June  1982)  (NHRC,  1982). 

The  findings  from  this  evaluation  corroborate  the  benefits  reported  by  the 
NHRC  system  developers.  There  were  four  principal  findings. 

1.  Prior  to  the  implementation  of  the  interim  system,  few  of  the 
workers  at  the  NARF  exposed  to  four  substances  that  require  monitoring 
(acrylonitrile,  asbestos,  benzene,  and  lead)  received  the  medical 
test(s)  required  because  of  their  exposure. 

2.  After  the  implementation  of  the  interim  system,  more  workers 
received  the  required  medical  tests  even  though  there  was  no  increase 
in  the  total  number  of  tests  performed.  In  fact,  there  was  a  decrease 
in  the  total  number  of  tests  performed,  from  323  in  February  1982  to 
208  in  June  1982. 

3.  As  a  result  of  the  interim  system,  proportionately  more 
medical  tests  were  being  performed  on  workers  with  critical  exposures. 


4.  As  a  result  of  the  interim  system,  proportionately  fewer 
medical  tests  were  being  performed  on  workers  with  no  exposure  to  any 
hazards. 


Summar) 


The  alternative  systems  to  NOHIMS  in  the  government  and  commercial  sectors 
that  were  identified,  described,  and  evaluated  in  the  June  1984  NOHIMS  System 
Decision  Paper  prepared  by  the  Navy  Environmental  Health  Center  were  discussed. 
Additional  systems  that  could  be  compared  to  NOHIMS  were  identified  from  a 
search  of  the  relevant  literature.  Analysis  of  these  systems  revealed  that  none 
met  Navy  requirements  and  none  equaled  the  capabilities  of  NOHIMS. 


NOHIMS  was  also  compared  to  a  semi-automated  interim  Navy  occupational 
health  system  that  preceded  it.  The  interim  system  was  implemented  to  test 
design  concepts  for  the  fully  automated  NOHIMS  and  to  provide  useful 
occupational  health  information  services  for  the  North  Island  Naval  Air  Rework 
Facility.  These  services  offered  a  preview  of  the  expanded  capabilities  that 
NOHIMS  was  later  to  deliver. 


Four  administrative  reports  were  produced  in  a  batch  operation  on  a  monthly 
or  semi-annual  basis  by  the  interim  system.  The  system  was  designed  to  collect 
only  the  data  needed  to  produce  these  four  reports.  It  was  not  designed  to  be 
able  to  retrieve  or  manipulate  data  stored  in  the  database.  That  capability  was 
deferred  to  NOHIMS.  The  interim  system  was  not  an  on-line,  interactive  system 
as  NOHIMS  was  later  to  be.  It  was  dictionary-driven,  limited  in  what  functions 
it  could  perform,  and  too  labor  intensive  for  any  long-term  implementation. 

Overall,  the  Naval  Health  Research  Center  (NHRC)  system  developers  who 
designed  and  developed  both  NOHIMS  and  the  interim  system  felt  that  the  interim 
system  was  adequate  for  its  intended  interim  purpose  but  that  it  was  inadequate 
as  a  long-term  operational  system.  The  NHRC  system  developers  perceived  a 
number  of  benefits  resulting  from  the  interim  system.  The  administrative 
reports  produced  by  the  interim  system  were  more  accurate  than  the  manually 
prepared  reports  they  replaced  and  increased  acceptance  of  the  NOHIMS  concept. 
They  also  perceived  considerable  improvement  in  the  appropriateness  of 
examinations  and  tests  performed  resulting  in  increased  efficiency  in  the  use  of 
resources . 

An  evaluation  of  the  effectiveness  and  impact  of  the  semi-automated  interim 
system  on  operational  procedures  at  the  Naval  Air  Rework  Facility  (NARF) 
dispensary  was  conducted  by  making  a  pre-  and  post-comparison  of  medical 
surveillance  for  workers  at  the  North  Island  NARF.  The  findings  from  this 
evaluation  corroborate  the  benefits  perceived  by  the  NHRC  developers  in  that 
after  the  introduction  of  the  interim  system,  more  workers  received  the  required 
medical  tests  even  though  there  was  no  increase  in  the  total  number  of  tests 
performed,  proportionately  more  medical  tests  were  being  performed  on  workers 
with  critical  exposures,  and  proportionately  fewer  medical  tests  were  being 
performed  on  workers  with  no  exposure  to  any  hazards. 
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APPENDIX  A 


THE  CONTENT  OF  STRUCTURED  INTERVIEWS  FOR 
TWELVE  CLASSES  OF  INDIVIDUALS  INVOLVED  WITH 
NOHIMS,  LISTING  THE  COMPONENTS  CONTAINED  IN 
EACH  INTERVIEW  GUIDE 


Component  1  A-6 

Component  2  A-8 

Component  3  A-10 

Component  4  A-12 

Component  5  A-14 

Component  6  A-44 

Component  7  A-46 

Component  8  A-49 

Component  9  A-50 

Component  10  A-52 

Component  11  A-54 

Component  12  A-60 

Component  13  A-62 

Component  14  A-64 

Component  13  A-65 

Component  16  A-66 

Component  17  A-68 

Component  18  A-69 

Component  19 


Component 

20 

A-72 

Component 

2! 

A-7  4 

Component 

22 

A-78 

Component 

23 

A-79 

Component 

24 

A-84 

Com poncnt 

25 

A-86 

Component 

26 

A-88 

Component 

27 

A-89 

Component 

28 

A-90 

Component 

29 

A-91 

Component 

30 

A-92 

Component 

31 

A-94 

Component 

32 

A-97 

Component 

33 

A- 100 

Component 

34 

A-101 

Component 

35 

A- 102 

Componen  L 

36 

A- 106 

Componen t 

37 

A-  1  1  0 

A-70 


CONTENT  OF  STRUCTURED  INTERVIEWS 

(NOTE:  The  numbers  below  corros;>ond  to  the  LIST 

OF  COMPONENTS  OF  STRUCTURED  INTERVIEWS) 


STRUCTURED  INTERVIEW  FOR  MEDICAL  CARE  PROVIDER  USERS 

2.  Perceived  goals  for  NOHIMS/Assessment  of  how  well  perceived 
goals  for  NOHIMS  were  met 

7.  Use  and  usefulness  of  information  retrieval  capabilities 
10.  Assessment  of  user  friendliness  of  NOHIMS 
13.  Adequacy  of  security  features 

19.  Suitability  of  NOHIMS  to  Navy  information  processing  needs 

20.  Assessment  of  system  performance 

21.  Attitude  appraisal 

23a.  Medical  monitoring  and  care  goa Is/ Assessment  of  how  well 
medical  monitoring  and  care  goals  are  being  met 
23b.  Assessment  of  increase  in  communication  between  departments 

31.  Implementation  process  at  test  sites 

32.  Acceptability  of  NOHIMS  to  users 

33.  Assessment  of  transferability  of  NOHIMS  to  other 
Navy  industrial  sites 

34.  Perceived  benefits  of  NOHIMS 


STRUCTURED  INTERVIEW  FOR  INDUSTRIAL  USERS 

2.  Perceived  goals  for  NOHIMS/Assessment  of  how  well  perceived 
goals  for  NOHIMS  were  met 

7.  Use  and  usefulness  of  information  retrieval  capabilities 
10.  Assessment  of  user  friendliness  of  NOHIMS 
13.  Adequacy  of  security  features 

19.  Suitability  of  NOHIMS  to  Navy  information  processing  needs 

20.  Assessment  of  system  performance 

21.  Attitude  appraisal 

23b.  Assessment  of  increase  in  communication  between  departments 

31.  Implementation  process  at  test  sites 

32.  Acceptability  of  NOHTMS  to  users 

33.  Assessment  of  transferability  of  NOHIMS  to  other 
Navy  industrial  sites 

34.  Perceived  benefits  of  NOHIMS 


STRUCTURED  INTERVIEW  FOR  DATA  ENTRY  PERSONNEL 

10.  Assessment  of  user  friendliness  of  Noil  IMS 

20.  Assessment  of  system  performance 

21.  Attitude  appraisal 


CONTENT  OF  STRUCTURED  INTERVIEWS  (CONT.) 


STRUCTURED  INTERVIEW  FOR  CONTRACTED  NOHIMS  DEVELOPERS 

3.  Programming  structure  and  language  used 
4b.  Minimum  requirements  for  hardware 

5.  System  description  (options,  features,  and  functions) 

8.  Software  quality  attributes 

9.  Operational  characteristics 

11.  Information  retrieval  capabilities 

12.  Security  features 

14.  Software  support  requirements 

17.  System  scenarios  to  maintain  the  system 

18.  Organizational  requirements 

22.  Appropriate  scenarios  for  system  testing 

30.  Features  that  make  NOHIMS  flexible  and  adaptable 

34.  Perceived  benefits  of  NOHIMS 


STRUCTURED  INTERVIEW  FOR  NHRC  NOHIMS  DEVELOPERS 

1.  Stated  Navy  goals  for  NOHIMS/Assessment  of  how  well  Navy  goals 
for  NOHIMS  were  met 

2.  Perceived  goals  for  NOHIMS/Assessment  of  how  well  perceived 
goals  for  NOHIMS  were  met 

4a.  Current  hardware  configuration 

6.  Description  of  system  users 

13.  Adequacy  of  security  features 

15.  Hardware  support  requirements 

16.  Available  system  support 

17.  System  scenarios  to  maintain  the  system 

18.  Organizational  requirements 

19.  Suitability  of  NOHIMS  to  Navy  Information  processing  needs 

22.  Appropriate  scenarios  for  system  testing 

23a.  Medical  monitoring  and  care  goal s/ Assessment  of  how  well 
medical  monitoring  and  care  goals  are  being  met 

27.  NOHIMS  as  an  aid  to  epidemiologic  research 

28a.  Uses  in  administrative  functions 

29.  Applicability  of  NOHIMS  to  other  Navy  industrial  sites 

31.  Implementation  process  at  test  sites 

33.  Assessment  of  transferability  of  NOHIMS  to  other 
Navy  industrial  sites 

34.  Perceived  benefits  of  NOHIMS 

35.  Suitability  of  government-owned  occupational  health  information 
systems  to  Navy  needs 

36.  Suitability  of  commercially  available  occupational  health 
information  systems  to  Navy  needs 

37a.  Description  of  Navy  interim  occupational  health  information  svstem 

37b.  Suitability  of  Navy  interim  occupational  health  information  system 
to  Navy  needs 


CONTENT  OF  STRUCTURED  INTERVIEWS  (CONT.) 


I 


STRUCTURED  INTERVIEW  FOR  NHRC  INTERIM  SYSTEM  DKVKI.OPKKS 

1.  Stated  Navy  goals  for  NOHIMS/Assessment  of  how  well  Navy  goals 
for  NOHIMS  were  met 

2.  Perceived  goals  for  NOHIMS/Assessment  of  how  well  perceived 
goals  for  NOHIMS  were  met 

19.  Suitability  of  NOHIMS  to  Navy  information  processing  needs 
34.  Perceived  benefits  of  NOHIMS 

37a.  Description  of  Navy  interim  occupational  health  information  system 
37b.  Suitability  of  Navy  interim  occupational  health  information  system 
to  Navy  needs 


STRUCTURED  INTERVIEW  FOR  TEST  SITE  ADMINISTRATORS 

2.  Perceived  goals  for  NOHIMS/Assessment  of  how  well  perceived 
goals  for  NOHIMS  were  met 

6.  Description  of  system  users 

7.  Use  and  usefulness  of  information  retrieval  capabilities 
10.  Assessment  of  user  friendliness  of  NOHIMS 

13.  Adequacy  of  security  features 

19.  Suitability  of  NOHIMS  to  Navy  information  processing  needs 

20.  Assessment  of  system  performance 

21.  Attitude  appraisal 

28a.  Uses  in  administrative  functions 

28b.  Assessment  of  usefulness  of  NOHIMS  in  administrative  functions 

31.  Implementation  process  at  test  sites 

32.  Acceptability  of  NOHIMS  to  users 

33.  Assessment  of  transferability  of  NOHIMS  to  other 
Navy  industrial  sites 

34.  Perceived  benefits  of  NOHIMS 


STRUCTURED  INTERVIEW  FOR  SYSTEM  MANAGERS 

2.  Perceived  goals  for  NOHT MS /Assessment  of  how  well  perceived 
goals  for  NOHIMS  were  met 

6.  Description  of  system  users 

7.  Use  and  usefulness  of  information  retrieval  capabilities 
10.  Assessment  of  user  friendliness  of  NOHIMS 

13.  Adequacy  of  security  features 

17.  System  scenarios  to  maintain  the  svstem 

20.  Assessment  of  system  performance 

21.  Attitude  appraisal 

22.  Appropriate  scenarios  for  system  testing 
31.  Implementation  process  at  test  sites 

33.  Assessment  of  transferability  of  NOHIMS  to  other 
Navy  industrial  sites 

34.  Perceived  benefits  of  NOHIMS 


CONTENT  OF  STRUCTURED  INTERVIEWS  (CONT.) 


STRUCTURED  INTERVIEW  FOR  HIGHER  LEVEL  NAVY  MANAGEMENT 

1.  Stated  Navy  goals  for  NOHIMS/Assessment  of  Low  well  Navy  goals 
for  NOHIMS  were  met 

2.  Perceived  goals  for  NOHIMS/Assessntent  of  how  well  perceived 
goals  for  NOHIMS  were  met 

13.  Adequacy  of  security  features 

19.  Suitability  of  NOHIMS  to  Navy  information  processing  needs 
28a.  Uses  in  administrative  functions 

28b.  Assessment  of  usefulness  of  NOHIMS  in  administrative  functions 
29.  Applicability  of  NOHIMS  to  other  Navy  industrial  sites 

33.  Assessment  of  transferability  of  NOHIMS  to  other 
Navy  industrial  sites 

34.  Perceived  benefits  of  NOHIMS 


STRUCTURED  INTERVIEW  FOR  NEHC  PROJECT  MANAGEMENT  TEAM 

1.  Stated  Navy  goals  for  NOHIMS/Assessment  of  how  well  Navy  goals 
for  NOHIMS  were  met 

2.  Perceived  goals  for  NOHIMS/Assessment  of  how  well  perceived 
goals  for  NOHIMS  were  met 

13.  Adequacy  of  security  features 

19.  Suitability  of  NOHIMS  to  Navy  information  processing  needs 

23a.  Medical  monitoring  and  care  goals/Assessment  of  how  well 
medical  monitoring  and  care  goals  are  being  met 

29.  Applicability  of  NOHIMS  to  other  Navy  industrial  sites 

33.  Assessment  of  transferability  of  NOHIMS  to  other 
Navy  industrial  sites 

34.  Perceived  benefits  of  NOHIMS 

35.  Suitability  of  government-owned  occupational  health  information 
systems  to  Navy  needs 

36.  Suitability  of  commercially  available  occupational  health 
information  systems  to  Navy  needs 

37b.  Suitability  of  Navy  interim  occupational  health  information  system 
to  Navy  needs 


STRUCTURED  INTERVIEW  FOR  NAVY  LEGAL  COUNSEL 

24.  Information  required  for  Navy  legal  purposes 

25.  Assessment  of  how  well  NOHIMS  meets  Navy  legal  needs 

26.  Appropriate  scenarios  for  testing  of  legal  interrogatories 
34.  Perceived  benefits  of  NOHIMS 


STRUCTURED  INTERVIEW  FOR  NHRC/ BREMERTON  ADP  PERSONNEL 


4  a 

15. 

16. 
17. 


Current  hardware 
Hardware  support 
Available  system 
System  scenarios 


con  f i gu ra  t i on 
requ i remen t  s 
support 

to  maintain  the 


system 


LIST  OF  COMPONENTS  OF  STRUCTURED  INTERVIEWS 


1.  Stated  Navy  goals  for  NOHIMS/Assessment  of  how  well  Navy  goals 
for  NOHIMS  were  met 

2.  Perceived  goals  for  NOHIMS/Assessment  of  how  well  perceived  goals 
for  NOHIMS  were  met 

3.  Programming  structure  and  language  used 

4a.  Current  hardware  configuration 

4b.  Minimum  requirements  for  hardware 

5.  System  description  (options,  features,  and  functions) 

6.  Description  of  system  users 

7.  Use  and  usefulness  of  information  retrieval  capabilities 

8.  Software  quality  attributes 

9.  Operational  characteristics 

10.  Assessment  of  user  friendliness  of  NOHIMS 

11.  Information  retrieval  capabilities 

12.  Security  features 

13.  Adequacy  of  security  features 

14.  Software  support  requirements 

15.  Hardware  support  requirements 

16.  Available  system  support 

17.  System  scenarios  to  maintain  the  system 

18.  Organizational  requirements 

19.  Suitability  of  NOHIMS  to  Navy  information  processing  needs 

20.  Assessment  of  system  performance 

21.  Attitude  appraisal  (a  self-administered  questionnaire; 
not  part  of  structured  interview) 

22.  Appropriate  scenarios  for  system  testing 

23a.  Medical  monitoring  and  care  goals/Assessment  of  how  well  medical 
monitoring  and  care  goals  are  being  met 
23b.  Assessment  of  increase  in  communication  between  departments 

24.  Information  required  for  Navy  legal  purposes 

25.  Assessment  of  how  well  NOHIMS  meets  Navy  legal  needs 

26.  Appropriate  scenarios  for  testing  of  legal  interrogatories 

27.  NOHIMS  as  an  aid  to  epidemiologic  research 
28a.  Uses  in  administrative  functions 

28b.  Assessment  of  usefulness  of  NOHIMS  in  administrative  functions 

29.  Applicability  of  NOHIMS  to  other  Navy  industrial  sites 

30.  Features  that  make  NOHIMS  flexible  and  adaptable 

31.  Implementation  process  at  test  sites 

32.  Acceptability  of  NOHIMS  to  users 

33.  Assessment  of  transferability  of  NOHIMS  to  other  Navy 
industrial  sites 

34.  Perceived  benefits  of  NOHIMS 

35.  Suitability  of  government -owned  occupational  health  information 
systems  to  Navy  needs 

36.  Suitability  of  commercially  available  occupational  health 
information  systems  to  Navy  needs 

37a.  Description  of  Navy  Interim  occupational  health  information  svstem 
37b.  Suitability  of  Navy  interim  occupational  health  information  svstem 
to  Navy  needs 
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COMPONENT  1 


STATED  NAVY  GOALS  FOR  NOHIMS/ASSESSMENT  OF  HOW  WELL  NAVY  COALS  FOR  NOIIIMS 
WERE  MET 


1.  It  is  my  understanding  that  the  intended  Navy  primary  goals  for 
NOHIMS  are/were  to 


a 


meet  OSHA  requirements/ 

improve  medical  surveillance/ 

improve  workplace  monitoring/ 

provide  data  for  epidemiologic  analysis/ 

improve  patient  care/ 

improve  coordination  between  departments/ 

provide  management  data/ 

improve  access  to  care/ 

improve  manpower  utilization/ 

improve  resources  utilization/ 

provide  data  for  legal  functions/ 

other : 


r:- 


2.  The  stated  Navy  goals  came  about  in  response  to 

administrative  direction/ 
legal  obligations/ 
need  felt  by  medical  staff/ 
need  felt  by  medical  research/ 
public  demand/ 
political  pressure/ 
organized  group  pressure/ 
worker  demand/ 
other : 


3.  I  consider  NOHIMS  in  its  present  state  to  be  meeting  these  Navy 
goals 

very  well/ 
somewhat  well/ 
somewhat  not  well/ 
not  well. 

A.  The  specific  goals  that  NOHIMS  is  not  meeting  very  well  are  to 

meet  OSHA  requirements/ 

improve  medical  surveillance/ 

improve  workplace  monitoring/ 

provide  data  for  epidemiologic  analysis/ 

improve  patient  care/ 

improve  coordination  between  departments/ 

provide  management  data/ 

improve  access  to  care/ 

improve  manpower  utilization/ 

improve  resources  utilization/ 

provide  data  for  legal  functions/ 

other : 
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The  reasons  that  NOHIMS  is  not  meeting  the  goal (s)  are 

NOHIMS  lacks  essential  function(s) 

Specify:  _  _ 

feature (s)  are  not  implemented 

Specify:  ___ _ 

feature (s)  are  not  implemented  well 

Specify:  _ _ 

other : 


The  goals  that  have  been  only  partially  achieved  are  to 


meet  OSHA  requirements/ 

improve  medical  surveillance/ 

improve  workplace  monitoring/ 

provide  data  for  epidemiologic  analysis/ 

improve  patient  care/ 

improve  coordination  between  departments/ 

provide  management  data/ 

improve  access  to  care/ 

improve  manpower  utilization/ 

improve  resources  utilization/ 

provide  data  for  legal  functions/ 

other : 


The  reasons  that  NOHIMS  has  only  partially  achieved  these  goals  are 


NOHIMS  lacks  essential  function(s) 
Specify:  _ 


feature (s)  are  not  implemented 
Specify:  _ 

feature(s)  are  not  implemented  well 
Specify : 


COMPONENT  2 


PERCEIVED  GOALS  FOR  NOHIMS/ASSESSMENT  OF  HOW  WELL  PERCEIVED  COALS  FOR  NOHIMS 
WERE  MET 

1.  My  personal  goals  for  NOHIMS  are /were  to 

meet  OSHA  requirements/ 

improve  medical  surveillance/ 

improve  workplace  monitoring/ 

provide  data  for  epidemiologic,  analysis/ 

improve  patient  care/ 

improve  coordination  between  departments/ 

provide  management  data/ 

improve  access  to  care/ 

improve  manpower  utilization/ 

improve  resources  utilization/ 

provide  data  for  legal  functions/ 

other : 


2.  I  consider  NOHIMS  in  its  present  state  to  be  meeting  these  goals 

very  well/ 
somewhat  well/ 
somewhat  not  well/ 
not  well. 

3.  The  specific  goals  that  NOHIMS  is  not  meeting  very  well  are  to 

meet  OSHA  requirements/ 

improve  medical  surveillance/ 

improve  workplace  monitoring/ 

provide  data  for  epidemiologic  analysis/ 

improve  patient  care/ 

improve  coordination  between  departments/ 

provide  management  data/ 

improve  access  to  care/ 

improve  manpower  utilization/ 

improve  resources  utilization/ 

provide  data  for  legal  functions/ 

other : 


The  reasons  that  NOHIMS  is  not  meeting  the  goal (s)  are 
NOHIMS  lacks  essential  function(s) 

Specify:  _ _  _  _ 

feature(s)  are  not  implemented 

Specify:  _ _  _ _ 

feature(s)  are  not  implemented  well 
Spec l f  v : 


The  goals  that  have  been  only  partially  achieved  are  to 

meet  OSHA  requirements/ 

improve  medical  surveillance/ 

improve  workplace  monitoring/ 

provide  data  for  epidemiologic  analysis/ 

improve  patient  care/ 

improve  coordination  between  departments/ 

provide  management  data/ 

improve  access  to  care/ 

improve  manpower  utilization/ 

improve  resources  utilization/ 

provide  data  for  legal  functions/ 

other : 


The  reasons  that  NOHIMS  has  only  partially  achieved  these  goals  arc 

NOHIMS  lacks  essential  function (s) 

Specif  v : 

feature (s)  are  not  implemented 

Specify:  _ _ _ _ 

feature (s)  are  not  implemented  well 
Specify: 


COMPONENT  3 


PROGRAMMING  STRUCTURE  AND  LANGUAGE  USED 

1.  The  system  routines  for  the  medical  component  of  NOHTMS  were 
written  by 

a  vendor/ 
consultants/ 
research  personnel/ 
clinical  personnel/ 
professional  programmers. 

2.  The  system  routines  for  the  industrial  component  of  NOHIMS 
were  written  by 

a  vendor/ 
consultants/ 
research  personnel/ 
clinical  personnel/ 
professional  programmers. 

3.  Their  operation  was  verified  by 

the  vendor/ 
consultants/ 
research  personnel/ 
clinical  personnel/ 

professional  data  processing  staff, 
through 

a  formal  check-out  procedure/ 
pilot  operation/ 
routine  operational  use. 

A.  The  principal  programming  language  is 

Assembler/ 

FORTRAN/ 

COBOL/ 

PL/1/ 

MUMPS/ 

Other : 


5.  The  programming  structure  is 

incremental / 
hierarch  ica 1 / 
structured  programming. 

f>.  The  routines  were  designed  and  written  for 

this  application/ 
general  medical  purposes/ 
general  commercial  purposes/ 
general  occupational  health  purposes. 


The  software  Is  now  being 

further  developed /ma i ntai nod/ unde rs tood / i gnored 
by  the  local  staff/ 

further  developed/maintained/ i gnored  by  the 
authors . 

The  file  system  is  characterized  by 

sequential  files/ 
tabular  files/ 
indexed  files/ 

direct  access  (random  files)/ 
linked  records/ 

hierarchical  direct  access  B-tree  files. 

The  files  are 

compressed/f ixed  length/variable  length. 

File  space  is  dynamically/pre-a 1 1  oca  ted . 

NOHIMS  uses 

foreground  interactive  processing/ 
equal  foreground/background  processing/ 
background/batch  processing/ 

for  most  of  its  processing. 


COMPONENT  4 


CURRENT  HARDWARE  CONFIGURATION  AND  MINIMUM  REQUIREMENTS  FOR  HARDWARE 


4A  Current  Hardware  Configuration 


1.  The  processing  capability  is  provided  through  the  following 
'  computer(s) 


Manufacturer 


Mode  l 


Year 

Installed 


2.  The  computing  services  are  provided  through  a 

vendor: _ _____ _ _ _ _ _ 

associated  organization:  _  _ 

in-house . 

3.  The  equipment  is  rented/leased/purchased. 

4.  Maintenance  is  by  vendor/in-house . 

5.  Approximately  _ %  of  the  processing  capability  is  used  for  NOHIMS. 


A.  Approximately 
NOHIMS. 


(%  or  actual)  of  the  file  capability  is  used  for 


7a.  The  files  are  stored  on 


Model 


b.  Communication  equipment  includes 


c.  Other  important  equipment  is 


d.  Archival  storage  is 


Hardcopy  terminals  are 

Char . / 

No.  Type  line 


Speed  Median  ism 


Re  1  i  a  - 
hi  1  i  t v 


■-  N  %  S  -  ~ 

/  .•  /  .*  /  s  „■»  ,*  /  „* 

-  '‘  A  A  A  /.  A 


*.  *-  '  \ 


9.  Softcopy  terminals  are 

Char./  U/L  Lines/  Relia-  Character 

No.  Type  Screen  line  case  Speed  screen  bilitv  resolution 


10.  Currently  production  occupies  _ %  of  the  machine, 

and  development  _ %. 

11.  Of  the  production  load 

_ %  is  data  entry, 

_ %  is  file  maintenance, 

_ %  is  data  analysis,  and 

%  is  report  preparation. 

12.  The  operating  system  was  designed  and  written 

for  this  application  and/or  institution/ 
for  general  medical  purposes/ 
for  general  commercial  purposes. 

13.  It  is  now  being 

further  developed/maintained /understood / i gnored 
by  the  local  staff/ 
further  developed/maintained/ i gnored 
by  the  original  supplier. 

Minimum  Hardware  Requirements 

14.  The  minimum  hardware  configuration  that  could  support  NOHIMS  is 

Processor:  _ 


Terminals : 


File  Storage: 


Communications  Equipment: 


-»|.  ■»*.  .1 


COMPONENT  5 


SYSTEM  DESCRIPTION  (OPTIONS,  FEATURES,  AND  FUNCTIONS) 


1.  What  are  the  primary  system  options  in  the  medical  component  of 
NOHIMS?  What  is  the  function  of  each  of  these  options?  What 
suhoptions  are  available  under  each  system  option? 

Registration:  _ _ _ _ 


Enter  Medical  Data: 


Display  Medical  Data: 


Print  Medical  Data: 


System  Maintenance: 


COSTAR  Report  Generator: 


Occupational  Health  Information: 


What  are  the  main  functions  and  features  of  each  of  the  options  in 
the  medical  component  of  NOHIMS? 

Re gistration:  Patient  Re gistrat ion /Edit 

Can  patients  already  entered  in  the  database  he  adequately 
identified  in  order  to  avoid  duplicate  registrations? 

Can  patients  be  identified  with  ambiguous  entries? 

Are  patient  names  searched  by  phonetics? 

Can  a  patient  unit  number  be  assigned  bv  the  system?  by 
the  clinic? 

Can  the  sequence  of  registration  entrv  items  be  altered  to 
add  new  items?  delete  items?  require  items?  not  require 
items?  change  the  sequence  of  prompts?  change  the  name  of 
the  prompts?  provide  range  cheeking? 

Can  the  possible  responses  to  the  items  in  the  registration 
sequence  be  changed? 

What  are  the  limits  on  the  number  of  items  that  can  lie 
entered  for  a  patient  during  registration? 


Are  items  that  are  not  applicable  skipped  automatically? 

Is  there  any  limitation  to  the  kinds  of  data  that  can  be 
entered  during  registration? 

Are  there  conventions  which  minimize  the  keystrokes 
required  at  each  prompt? 

Are  the  entries  made  displayed  on  the  screen  during  data 
entry?  Does  the  screen  display  during  data  entry  duplicate 
the  input  documents? 

Can  the  user  redisplay  the  data  entered  to  be  certain  that 
all  entries  are  correct? 

Can  the  display  of  registration  items  be  formatted  in  any 
manner  desired? 

Are  there  any  features  that  verify  the  entry  of  data? 

What  requirements  are  there  for  the  input  documents  for 
registration? 

What  methods  can  be  used  to  enter  data  such  as  keypunch, 
optical  scanning,  bar  code  reading,  CRT  entry,  or  direct 
machine  interface? 

Can  data  be  kept  historically  for  selected  data  items? 

Can  incorrect  entries  be  edited  before  filing? 

Can  the  user  select  the  specific  data  item  that  needs 
editing? 

Is  the  patient  registration  information  filed  in  the 
background  while  registration  proceeds? 

Is  there  help  text  for  the  registration  sequence? 

Can  help  text  for  the  registration  sequence  be  changed? 

Describe  any  additional  features  of  this  option. 

Enter  Medical  Data:  Encounter 

What  defines  an  encounter  for  NOHIMS? 

Can  more  than  one  encounter  be  entered  on  a  given  dav? 

Can  an  encounter  be  entered  if  a  patient  has  not  been 
regi stered? 

Can  the  prompt  sequence  for  the  header  of  the  encounter  be 
altered  to  change  the  sequence?  add  items?  delete  items? 
perform  range  checking?  change  prompt  names?  require  items? 
not  require  items? 

Does  the  patient  record  need  to  be  identified  for  each 
encounter  entered  into  the  database? 

Can  possible  responses  to  tiie  items  in  tiie  header  sequence 
be  changed? 

Is  there  help  text  for  the  encounter  header  entrv  sequence? 


A-15 


Can  help  text  for  the  encounter  header  entry  sequence  be 
changed? 

Can  the  providers  of  care  for  the  encounters  be  entered  in  a 
table  that  is  referred  to  by  the  prompt  sequence?  Can  changes 
be  made  to  this  table? 

Is  there  any  limitation  to  the  types  of  data  that  can  be 
entered  during  the  header  portion  of  the  encounter? 

Can  the  sequence  for  entering  data  during  the  body  portion 
of  the  encounter  be  altered? 

Is  there  any  limitation  to  the  types  of  data  that  can  be 
entered  during  the  body  portion  of  the  encounter? 

Can  the  items  to  be  entered  during  the  body  portion  of  the 
encounter  be  augmented  to  assign  abnormal  statuses?  assign 
other  statuses? 

Can  lab  results  be  entered  during  encounter  entry? 

Can  a  panel  of  tests  be  specified?  Can  the  individual  tests 
be  specified? 

Is  help  text  available  for  the  entry  of  data  in  the  body  of 
the  encounter? 

Are  the  entry  procedures  the  same  for  each  class  of  data  item? 

What  is  the  minimum  amount  of  information  required  to  enter 
data  in  the  system?  Is  there  more  than  one  way  to  enter  a 
particular  item? 

Are  there  any  short-cut  methods  to  enter  the  data? 

Are  there  conventions  that  minimize  the  keystrokes  required 
at  each  prompt? 

Does  a  data  item  have  to  be  predefined  in  NOHTMS  before  it 
can  be  entered? 

Can  free  text  be  associated  with  codes? 

Can  additional  codes  be  added  to  the  directory? 

Can  features  of  these  codes  be  changed  at  will? 

Can  NOHIMS  be  told  to  automatically  prompt  for  text? 

Can  NOHIMS  be  told  to  require  that  a  modifier  be  entered? 

Can  special  input/output  formats  be  specified  for  selected 
data  items? 

What  restrictions  are  there  on  the  short  name  of  a  code? 

What  restrictions  are  there  on  the  long  name  of  a  code? 

What  is  the  significance  of  the  COSTAR  code?  the  COSTAR 
taxonomy? 

What  functions  does  the  modifier  play?  How  is  it  useful  in 
the  NOHIMS  application? 

Can  codes  be  blocked  from  encounter  entry? 


What  other  input  conditions  can  be  set  for  codes  entered 
during  encounter  entry? 

Can  flowcharts  be  triggered  by  the  entry  of  a  code  in  the 
patient's  medical  record? 

Does  NOHIMS  perform  range  checking  on  results  and 
findings?  What  criteria  can  be  specified  for  range 
checking? 

Are  the  entries  made  displayed  on  the  screen  during  entry? 
Does  the  screen  display  during  entry  duplicate  the  input 
documents? 

Can  changes  be  made  to  the  information  already  entered  for 
a  patient  while  in  the  encounter  option? 

What  methods  can  be  used  to  enter  data  such  as  keypunch, 
optical  scanning,  bar  code  reading,  CRT  entry,  or  direct 
machine  interface? 

What  requirements  are  there  for  the  input  documents  for 
encounter  entry? 

Are  all  codes  to  be  entered  into  NOHIMS  precoded  on  the  data 
collection  forms?  Who  codes  data  that  are  not  precoded? 

Are  there  any  features  that  verify  entry  of  the  data?  Does 
the  COSTAR  code  have  a  check  digit? 

Is  the  information  entered  during  encounter  entry  filed  in 
the  background/using  transaction  processing/batch  processing 
When  are  the  input  data  reflected  in  the  files? 

Can  another  encounter  be  entered  while  data  are  being  filed 
to  a  patient  record? 

Describe  any  additional  features  of  this  option. 

En te r  Medical  Data:  Medical  Edit 

Can  the  patient  record  to  be  edited  be  identified  with  an 
ambiguous  entry? 

Can  the  patient  record  to  be  edited  be  identified  by  name? 
by  social  security  number?  by  unit  number? 

Is  the  patient  record  to  be  edited  displayed  before  editing 
is  done? 

Can  all  data  items  be  edited?  lie  deleted? 

Can  the  user  select  the  specific  item  that  needs  editing? 

What  is  the  format  for  editing  a  data  item? 

Is  editing  done  on-line  or  with  a  special  batch  program? 

When  are  changes  reflected  in  the  files? 

Is  an  item  which  is  deleted  actually  removed  from  the 
patient  record? 

Are  old  results  and  free  text  associated  with  codes  that 
have  been  edited  actually  removed  from  the  patient  record? 


Is  an  audit  trail  of  all  entry  errors  maintained? 

Does  editing  an  encounter  affect  the  display  of  the  encounter? 

When  a  correction  is  made,  are  all  previously  derived  reports/ 
fields  automatically  corrected  or  are  changes  entered  in  the 
file  only? 

Can  an  entire  encounter  be  deleted? 

Can  a  generic  edit  be  accomplished  such  as  deleting  all 
laboratory  codes? 

Are  the  edits  made  displayed  on  the  screen  during  editing? 

Are  there  any  features  that  verify  the  editing  of  data? 

What  requirements  are  there;  for  the  input  documents  for 
editing  an  encounter? 

Describe  any  additional  features  of  this  option. 

Enter  Medical  Data:  Lab  Results 

Can  the  patient  for  whom  lab  results  are  to  be  entered  he 
identified  with  an  ambiguous  entry? 

Can  the  patient  for  whom  lab  results  are  to  be  entered  be 
identified  by  name?  by  social  security  number?  by  unit  number? 

Does  the  patient  record  need  to  be  identified  for  each  lab 
result  entered? 

How  is  the  proper  lab  test  to  be  resulted  identified? 

Can  lab  results  be  entered  for  a  date  that  does  not  have  an 
encounter? 

Can  lab  results  be  entered  for  a  test  that  has  not  been 
recorded  in  the  encounter? 

Are  there  short  cuts  to  entering  lab  results  data? 

Can  panels  of  tests  be  resulted  as  a  group?  can  individual 
tests  be  resulted? 

Do  all  tests  in  a  panel  have  to  be  resulted  at  the  same  time? 

Are  there  any  features  that  verify  the  entry  of  data?  Is  range 
checking  performed  on  the  lab  results  entry? 

What  limitations  are  there  on  the’  format  for  entering  lab 
results  data? 

Can  free  text  be  entered  with  a  lab  result? 

Can  NOHIMS  interpret  lab  results?  What  criteria  are  used  to 
interpret  the  results?  Can  these  criteria  be  changed  easily? 

Can  lab  results  be  edited  once  they  are  filed? 

Is  the  filing  of  lab  results  done  in  the  background? 

Does  NOHTMS  keep  track  of  the  status  of  a  lab  test  (ordered/ 
pending/ resulted) ? 

Are  there  conventions  that  minimize  the  keystrokes  required 
at  each  prompt? 
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Are  the  entries  made  displayed  on  the  screen  during  entry? 

Does  the  screen  display  during  entry  duplicate  the  input 
documents? 

Is  there  any  limit  to  the  number  of  lab  tests  that  can  be 
entered  for  a  given  patient  on  a  given  day? 

Can  more  than  one  lab  result  be  entered  for  a  lab  test  on 
the  same  day  (repeat  tests)? 

Can  special  input/output  sequences  be  used  for  tests  with 
several  components  such  as  urinalysis  and  pulmonary  function 
tests? 

Is  there  help  text  for  the  lab  results  entry?  Is  it  specific 
for  each  lab  test? 

Can  an  incorrectly  entered  lab  test  be  deleted  in  this  option? 

What  requirements  are  there  for  the  input  documents  for  the 
laboratory  results? 

Can  lab  results  be  automatically  entered  from  machines  or 
other  systems? 

Can  NOHIMS  automatically  generate  orders  for  laboratory  tests? 
Describe  any  additional  features  of  this  option. 

Display  Medical  Data* 

Print  Medical  Data* 

* 

Please  see  the  Information  Retrieval  Capabilities  section  of 
the  structured  interviews  for  questions  on  these  two  system 
options . 

System  Maintenance 


Please  see  the  Security  Features  section  of  the  structured 
interviews  for  questions  on  security  functions.  See  the 
Software  Quality  Attributes  and  Operational  Characteristics 
sections  of  the  structured  interviews  for  questions  on 
error  recovery  procedures  and  error  diagnostics. 

Can  the  functions  of  the  background  filing  job  (Monitor) 
be  controlled  without  programming  intervention? 

Does  NOHIMS  display  information  regarding  the  filing  status 
of  the  data? 

Can  a  variety  of  terminal  types  be  used  witli  NOHIMS? 

Can  the  codes  in  the  directory  be  printed  and/or  displayed 
for  review? 

Can  tlie  user  select  the  directory  codes  to  be  printed/ 
displayed  bv  division?  bv  other  rriteria? 

Can  the  user  specify  the  order  in  which  the  codes  arc  printed/ 
displayed  ? 
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What  ts  the  format  of  the  directory  pr i nt /d i spl ay?  Can  this 
format  be  altered  without  programming  intervention? 

Can  the  specifications  for  a  particular  code  be  reviewed? 

Can  the  specifications  for  a  particular  code  be  altered? 

Can  a  code  be  added  to  the  directory?  deleted  from  the 
directory? 

Can  patient  records  be  archived  to  tape?  retrieved  from  tape? 
to  and  from  other  media? 

What  selection  criteria  may  be  used  to  define  the  patient 
records  that  are  to  be  archived?  retrieved  from  the  archive? 

Is  there  a  zip  code  directory?  Can  the  zip  code  directory  be 
updated? 

Can  a  9-digit  zip  code  be  entered  in  the  directory? 

Can  jobs  run  on  the  system  be  queued  to  run  at  a  particular 
time  of  day  on  a  particular  date? 

Can  the  job  queue  be  altered  without  programming  intervention? 
Can  a  job  be  deleted  from  the  job  queue? 

Does  the  system  provide  a  profile  of  current  users  of  the 
system?  What  information  is  included  in  this  profile? 

Can  a  user  be  given  the  ability  to  review  the  specifications 
of  a  code  without  being  given  the  ability  to  alter  the  directory 

Is  there  help  text  for  the  system  maintenance  procedures? 

Describe  any  additional  features  of  this  module. 

Mailbox 

Can  NOHIMS  store  messages  for  other  users  of  the  system? 

Can  a  message  be  sent  to  al 1  users?  to  a  selected  group  of 
users? 

Is  there  any  limitation  to  the  length  of  a  message? 

Can  a  message  be  edited  before  it  is  stored?  after  it  is 
stored? 

Does  NOHIMS  note  the  time  and  day  that  a  message  was  sent? 

Does  NOHIMS  tell  you  if  you  have  mail? 

Does  NOHIMS  keep  track  of  whether  you  have  read  your  mail? 

Can  NOHIMS  tell  you  if  others  have  read  the  mail  you  sent? 

Can  a  hardcopy  of  a  message  be  produced? 

Can  mail  be  selectively  deleted?  by  the  receiver?  by  the 
sender?  by  the  system  manager? 

Is  there  any  limitation  to  the  number  of  messages  that  can 
be  sent/stored  at  any  one  time? 

Is  there  help  text  for  the  mailbox  procedures? 

Describe  any  additional  features  of  this  module. 


Occupational  Health  Information 

Can  the  data  in  the  industrial  component  of  NOHTMS  he  accessed 
from  the  medical  component?  by  the  user?  by  the  system  for 
reports? 

Can  restrictions  be  placed  on  the  access  to  the  industrial 
component  ? 

Describe  any  additional  features  of  this  module. 

What  system  interfaces/relationships  does  NOHIMS  have  with  other  Navy 
and/or  non-Navy  data  systems? 

Does  NOHIMS  access  and  display  information  derived  from 
intra-  and  extra-Navy  databases  such  as  demographic  data 
from  personnel  databases,  safety  department  databases, 
and  hazard/toxic  chemical  databases? 

Does  NOHIMS  incorporate  or  replace  existing  central 
Asbestos  Medical  Surveillance  Program  (AMSP)  and 
HEaring  Conservation  Management  Information  System 
(HECMIS)  databases? 

Does  NOHIMS  utilize  historic  data  contained  in  AMSP 
and  HECMIS  databases? 

What  are  the  primary  options  in  the  industrial  component  of  NOHIMS? 
What  is  the  function  of  each  of  these  options?  What  suboptions 
are  available  under  each  system  option? 

Agency: _ _ _ _ 


Personnel : 


Environments : 


Surveys : 


Hazardous  Agent  Table: 


System  Maintenance: 


What  are  the  main  functions  and  features  of  each  of  the  options  in 
the  industrial  component  of  NOHTMS? 


INDUSTRIAL  COMPONENT  OF  NOH1MS 


PRIMARY  INFORMATION  TOPICS 


The  Industrial  Component  is  concerned  with  the  collection, 
control,  coodination  and  manipulation  of  the  five  specific  major 
topical  areas  of  information  as  given  below. 

The  design  of  this  component  specifically  attempts  to  record, 
maintain  and  assess  the  inter-relationship  of  these  data  in  order 
to  provide  automated  capabilities  that  satisfy  the  industrial 
related  information  objectives  of  the  NOHIMS  system. 

1.  The  Industrial  organization  (Agency). 

2.  The  employees  and  other  personnel  within  the  organization 
( Personnel ) . 

3.  The  work  environments  local  to  the  organization 
( Environments ) . 

4.  The  contents,  concentration  measurments,  configuration  and 
use  of  materials,  agents  and  conditions  of  the  work 
environments  (Surveys). 

5.  The  collection  and  application  of  information  related  to  the 
monitoring,  usage  and  health  care  aspects  of  chemical 
substances,  biological  elements  and  physical  phenomena 
(Hazardous  Agent  Table). 

The  following  interrogatory  scenarios  solicit  and  chronicle 
the  pertinent  technical,  functional  and  methodological  attributes 
and  features  that  are  incorporated  in  the  Industrial  component  as 
they  apply  to: 

1.  Each  of  the  above  major  topics. 

a.  Purpose  and  usage. 

b.  Identifier  entry,  edit,  update,  filing,  availability, 
retrieval  and  display  functions. 

c.  Associated  data  item  entry,  edit,  update,  filing, 
availability,  retrieval  and  display  functions. 

d.  Transaction  handling. 

e.  Inter-relation  to  other  major  topic  data. 

f.  Special  features. 

2.  System  objective  specific  functions. 

a.  Objective  description. 

b.  Initiation,  subject  and/or  data  item  identification 
and  selection. 

c.  Data  or  transaction  entry,  edit,  update  and  filing. 

d.  Retrieval,  organization  and  display. 

e.  Special  features. 

3.  System  Security  Functions. 

4.  System  Tables,  Directory  and  utility  Maintenance. 

5.  System  Error  Recovery. 


AGENCY  FUNCTIONS  and  INFORMATION 


PURPOSE:  Describe  the  primary  objectives  that  the  system 

functions,  as  a  whole,  are  designed  to  provide,  achieve  or 
support  in  this  topic  area. 

IDENTIFIERS:  Include  explanations  or  comments  as  required. 

Can  a  local  or  ad  hoc  organizational  structure  be  defined  for 
use? 

Defined  by  whom?  <general  user/system  manager/system 
implementor/ADP  prof essional> 

Can  one  or  more  geographical  locations  (sites)  local  to  the 
industry  be  defined  within  the  ogani zat ional  definition? 
With  user-specific  identifiers? 

With  additional  user-selected  acronyms? 

Can  the  hierarchical  levels  and  associated  titles  of  the 
organizational  structure  be  defined? 

With  user-specific  title  identifiers? 

Can  the  association  between  hierarchical  level  and  work  unit 
defined? 

Can  it  represent  the  true  relationship  of  work  units  at  e; 
hierarchical  level? 

Can  it  represent  the  true  relationship  of  work  units  at 
hierarchical  levels  above  and  below  any  specified  level? 

Can  each  individual  work  unit  be  defined? 

With  user-specific  identifiers? 

With  additional  acronyms  or  user-specific  codes? 

Is  the  site  location  of  the  work  unit  associated  with  it? 
Can  a  work  unit  reside  at  more  than  one  site? 

ASSOCIATED  DATA:  Provide  a  list  of  data  items  that  are 

intrinsically  solicited  relative  to  the  AGENCY  topic  or 
identifiers.  Include  any  necessary  description. 


UPDATE  CAPABILITY: 


Can  the  original  organizational  definition  be  altered,  updated, 
expanded,  deleted  and  generally  manipulated? 

Are  alterations  that  are  made  reflected  throughout  the  applicable 
elements  of  the  hierarchical  structure? 

Is  there  an  update  capability  for  individual  work  unit  name, 
acronym  or  code  identifiers? 

Historical  retention  of  previous  identifiers? 

Additional  work  unit  definition  capability? 

For  all  existing  work  units  at  any  hierarchical  level? 
Historical  retention  of  the  previous  configuration  of  the 
augmented  work  unit? 

Can  individual  work  units  be  deleted  or  de-aetivated? 

Historical  retention  of  the  unit  identifiers  and  their 
location  within  the  organizational  hierarchy? 

Can  the  hierarchical  structure  levels  be  increased? 

Historical  retention  of  the  previous  con f iguration? 

Can  the  hierarchical  level  title  identifiers  be  changed? 

Historical  retention  of  the  previous  title  identifiers? 

Can  a  work  unit  be  relocated  in  the  hierarchical  structure? 
Historical  retention  of  previous  configuration? 

By  whom  can  the  above  tasks  be  done?  <general  user/system 
manager/system  implemen tor/ADP  professional 

Does  the  update,  deletion  or  alteration  of  the  agency  structure 
or  identifier  configuration  require  any  system  software  or 
hardware  modifications? 

Describe  all  necessary  modification  requirements  and  indicate 
by  whom  they  are  to  be  performed. 

Can  the  associated  intrinsic  data  items  be  entered,  updated  and 
generally  manipulated  by  the  user? 

Is  a  historical  record  of  <each/  some/  specif ic>  altered  data 

item  retained? 

Can  additional  user  defined  data  items  be  included  in  topical 
data  groups  in  an  ad  hoc  manner? 

Describe  the  item  definition  capability. 

Does  the  user  have  the  same  general  update  capabilites  with 
ad  hoc  data  items  as  with  intrinsic  data  items? 
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EDITING: 


Are  identifier  entries  and  changes  edited  for  content, 
construction  and  applicable  omission  or  duplication 
restraints  by  <entry  process/  a  background  process/  a  batch 
process/  no  process>? 

Are  data  item  entries  and  changes  edited  for  content, 

construction  and  applicable  omission  or  duplication 
restraints  by  <entry  process/  a  background  process/  a  batch 
process/  no  process>? 

Describe  other  pertinent  edit  processes  or  considerations  that 
are  applied  to  these  data. 

FILING: 

Are  identifier  entries  and  alterations  filed  by  a  <foreground/ 
background/  batch>  process? 

Are  data  item  or  data  groups  filed  by  a  <f oreground/  background/ 
batch>  process? 

Describe  any  additional  features  of  AGENCY  entry,  editing, 

update,  deletion  or  general  management  of  these  functions. 

RETRIEVAL  &  DISPLAY:  Agency  Identifiers/data  items 

Responses  to  the  following  questions  are  not  to  include  the 
capabilities  of  general  "Query",  "Data  Base"  or  "Report 
Generator"  functions  that  may  be  present  in  the  system.  Only 
capabilities  available  in  the  "normal"  entry,  edit,  update 
and  display  functions  are  solicited  here. 

Unless  otherwise  noted,  it  is  assumed  that  data  and  groups  of 
data  that  are  retrievable  in  the  manner  indicated  can  also  be 
displayed  to  the  user  in  that  manner  or  made  available  to  any 
other  applicable  task  concerned  with  the  agency  and  agency 
data . 

Can  any  work  unit  at  all  hierarchical  levels  be  retrieved? 

All  work  units  under  a  specific  unit,  at  the  next  descendent 
hierarchical  level? 

All  work  units  under  a  specific  unit  at  all  descending 
hierarchical  levels  in  cascade  order? 

All  work  units  within  the  organization  in  cascade  order? 

All  work  units  at  any  specific  hierarchical  level? 

A  specific  group  of  work  units  at  the  same  hierarchical 
level? 

A  specific  group  of  work  units  and  their  respective 
descendent  work  units? 

A  random  user  specified  set  of  individual  work  units? 
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Can  a  specific  site  be  selected  for  retrieval  of  work  units? 

Can  sites  be  specified  by  acronym  or  ambiguous  entry? 

Can  retrieval  include  work  units  at  all  applicable  sites? 

Can  retrieval  of  work  units  be  accomplished  by  ambiguous 
identifier  entry? 

Does  the  system  construct  a  selection  list  of  all  possible 
subject  candidates  for  an  ambiguous  identifier  entry? 

Is  multiple  selection  from  the  candidate  list  allowed  if 
applicable  to  the  task? 

Is  selection  of  all  entries  of  a  candidate  list  allowed  if 
applicable  to  the  task? 

Does  the  retrieval  of  agency  elements  intrinsically  include 
pertinent  names,  acronyms,  code,  titles  and  site  data? 

List  items  included. 

For  applicable  tasks,  can  retrieval  optionally  include  pertinent 
identifiers  and/or  data  items  from  other  major  topic  data 
areas? 

Provide  a  list  of  topics  and  data  that  can  be  included. 
Identify  the  specific  tasks  or  functions  where  this  is 
allowed. 

Can  such  retrieval  include  any  desired  "agency"  associated  data 
item  or  data  group  in  an  ad  hoc  manner? 

Describe  the  means  of  data  item  selection  if  selection  is 
allowed. 

Identify  the  specific  tasks  or  functions  where  this  is 
allowed . 

Describe  any  additional  features  of  retrieval  of  AGENCY 
associated  system  elements. 

The  AGENCY  data  contains  or  directly  references: 

Work  environments  associated  with  an  agency  work  unit? 
Personnel  assigned  to  an  agency  work  unit? 

Survey  data  associated  with  an  agency  work  unit? 


The  AGENCY  data  contains  or  directly  references  what  other 

primary  or  pertinent  data  areas  within  the  system?  Describe. 


Example  response  to  AGENCY  usage: 

<<<Ex.  evaluation  finding  follows: 

To  provide  a  local  reference  for  the  placement,  movement, 
termination  and  other  transactions  related  to  personnel  and  work, 
environments . 

To  provide  a  local  means  of  collective  and  individual 
identification  and  selection  of  personnel. 

To  identify  and  relate  the  local  authority  over  work 
environments  and  personnel. 

To  provide  an  optimum  intrinsic  adaptation  capabil ity . >>> 
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PERSONNEL  FUNCTIONS  and  INFORMATION 


PURPOSE:  Describe  the  primary  objectives  that  the  system 

functions,  as  a  whole,  are  designed  to  provide,  achieve  or 
support  in  this  topic  area. 

IDENTIFIERS:  Include  explanations  or  comments  as  required. 

Is  there  an  intrinsic  limit  to  the  number  ot  personnel  that  may 
be  defined? 

Can  each  person  be  identified  by  actual  name? 

By  social  security  number? 

By  a  local  employee  or  pay  number? 

By  any  user-defined  ad  hoc  identifier  scheme? 

AGENCY  UNIT  AND  ENVIRONMENT  ASSIGNMENT: 

Can  each  person  be  assigned  to  any  agency  unit? 

Can  each  person  be  assigned  to  any  work  environment  that  is 
associated  with  the  assigned  agency  unit? 

Assigned  to  work  environments  associated  with  other  agency 
units? 

Assigned  to  multiple  work  environments? 

Is  duration  or  proportion  of  time  a  person  is  associated  with 
each  agency  unit  and  work  environment  maintained? 

In  an  historical  fashion? 

ASSOCIATED  DATA:  Provide  a  list  of  data  items  that  are 

intrinsically  solicited  relative  to  the  "PERSONNEL"  topic  or 
identifiers.  Include  any  necessary  description. 

EXPOSURE  AND  MEDICAL  MONITORING  REQUIREMENTS  DATA: 

Does  the  system  maintain  the  association  between  a  person  and  th 
actual  survey  information  for  each  applicable  work 
environment? 

Are  all  applicable  hazardous  agents,  concentration  measurement 
data  and  surveyed  conditions  considered  in  the  summarization 
of  personnel  medical  monitoring  requirement  and  exposure 
information? 

Are  all  applicable  agent-specific  mandatory  requirements 
considered  also? 

Are  user-specified  recommendations  or  local  requirements 
considered? 

Are  sex,  age  and  previously  established  medical  factors  and 
conditions  considered? 


.ihj; 


Is  a  list  of  specific  medical  requirements  established  for  each 
person? 

Listing  of  physical  examination  elements,  laboratory  testing 
and  other  medical  procedures  required? 

Are  relevant  or  applicable  elements  of  medical,  work  and 
family  history  noted? 

List  any  other  applicable  medically  oriented  information  that 
is  or  may  optionally  be  included. 

Is  a  list  of  applicable  hazardous  agents  and  materials 
summarized? 

Does  it  include  measured  concentration  data  for  each  agent? 

Does  the  system  provide  a  selection  and  report  capability  for  the 
exposure  data  and  medical  requirements  summary? 

For  an  individual  or  a  user-specified  ah  hoc  selection  of 
individuals? 

For  personnel  associated  with  user-selected  agency  units 
and/or  work  environments? 

For  a  given  personnel  data  item  criterion? 

Can  it  be  produced  at  any  user-desired  frequency? 

Can  it  provide  notification  of  requirements  to  both  the 
applicable  agency  authority  and  the  person? 

Does  it  historically  record  medical  action  taken,  results, 
cancellation  and  no-response  dispositions  for  the  medical 
requirements  produced? 

List  any  additional  attributes,  capabilities  or  elements  of 

consideration  that  are  applicable  to  the  personnel  exposure 
and  medical  requirements  information  area. 


UPDATE  CAPABILITY: 

Can  an  original  name,  social  security  number,  employee 

number  or  user-defined  personnel  identifier  be  updated? 

Is  the  previous  identifier  historically  maintained? 

Can  any  associated  intrinsic  data  items  be  entered,  updated  and 
generally  manipulated  by  the  user? 

Is  an  historical  record  of  <each/some/speci f ic>  altered  data 
item  retained? 

Can  the  personnel  to  agency  unit  and  work  environment 

relationships  be  established,  altered  and  terminated  by  the 
user  at  any  time? 

Historical  retention  of  the  previous  relationship? 

Can  the  induction,  assignment,  termination  and  within  agency 

transfer  transactions  involving  personnel  be  accomplished  by 
both  a  manual  foreground  interactive  process  and  a  background 
transaction  file  processing  task? 
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Are  the  effects  of  additional  and  updated  environment,  survey  and 
exposure  information  that  may  be  made  throughout  the  system 
immediately  reflected  in  the  personnel  medical  information? 

Are  alterations  that  are  made  reflected  throughout  the  applicable 
elements  of  associated  functions? 

By  whom  can  the  above  tasks  be  done?  <general  user/system 
manager/system  implementor/ADP  professional? 

Does  the  update,  deletion  or  alteration  of  any  personnel 

identifier  configuration  require  any  system  software  or 
hardware  modifications? 

Describe  all  necessary  modification  requirements  and  indicate 
by  whom  they  are  to  be  performed. 

EDITING: 

Are  identifier  entries  and  changes  edited  for  content, 
construction  and  applicable  omission  or  duplication 
restraints  by  <entry  process/background  process/batch 
process/no  process?? 

Are  data  item  entries  and  changes  edited  for  content, 

construction  and  applicable  omission  or  duplication 
restraints  by  <entry  process/background  process/batch 
process/no  process?? 

Describe  other  pertinent  edit  processes  or  considerations  that 
are  applied  to  these  data. 

FILING: 

Are  identifier  entries  and  alterations  filed  by  a  foreground./ 
background/batch?  process? 

Are  data  item  or  data  groups  filed  by  a  < 1 oreground/background/ 
batch?  process? 

Describe  any  additional  features  of  PERSONNEL  entry,  editing, 
update,  deletion  or  general  management  of  these  functions. 

RETRIEVAL  &  DISPLAY:  Work  environment  identifiers/data  items 

Responses  to  the  following  questions  are  not  to  include  the 
capabilities  of  general  "Query",  "Data  Base"  or  "Report 
Generator"  functions  that  may  be  present  in  the  system.  Only 
capabilities  available  in  the  "normal"  entry,  edit,  update 
and  display  functions  are  solicited  here. 

Unless  otherwise  noted,  it  is  assumed  that  data  and  groups  of 
data  that  are  retrievable  in  the  manner  indicated  can  also  be 
displayed  to  the  user  in  that  manner  or  made  available  to  any 
other  applicable  task  concerned  with  the  agency  and  agency 
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Can  any  individual  be  retrieved? 

By  name  entry"? 

By  social  security  number  entry? 

By  employee  number  or  other  user-adopted  identification 
scheme? 

By  the  association  of  a  person  to  an  agency  unit? 

By  the  association  of  a  person  to  a  work  environment? 

Can  retrieval  of  target  personnel  be  accomplished  by  specific 
ageny  unit,  work  environment  or  ambiguous  name  identifier 
entry? 

Does  the  system  construct  a  selection  list  of  all  possible 

subject  candidates  for  an  agency  unit,  work  environment  or 
ambiguous  identifier  entry? 

Is  multiple  selection  from  the  candidate  list  allowed  if 
applicable  to  the  task? 

Is  selection  of  all  entries  of  a  candidate  list  allowed  if 
applicable  to  the  task? 

Can  the  retrieval  of  personnel  rosters  and  data  be  done  for  any 
configuration  of  agency  unit  identification  data? 

For  any  configuration  of  environment  descriptor  data? 

For  applicable  tasks,  can  retrieval  optionally  include  exposure, 
medical  requirements  and  disposition  information? 

Provide  a  list  of  other  topics  and  data  that  can  be  included 
Identify  the  specific  tasks  or  functions  where  this  is 
allowed. 


Describe  any  additional  features  of  retrieval  of  PERSONNEL 
associated  system  elements. 

The  PERSONNEL  data  contains  or  directly  references: 

Agency  units  associated  with  a  person? 

Work  environments  assigned  to  a  person? 

Exposure  data  and  medical  health  care  requirements  tor  a 
person? 

The  PERSONNEL  data  contains  or  directly  references  what  other 

primary  or  pertinent  data  areas  within  the  system?  Describe 
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WORK  ENVIRONMENT  FUNCTIONS  and  INFORMATION 


PURPOSE:  Describe  the  primary  objectives  that  the  system 

functions,  as  a  whole,  are  designed  to  provide,  achieve  or 
support  in  this  topic  area. 


IDENTIFIERS:  Include  explanations  or  comments  as  required. 

Can  local  physical  location  and  area  descriptors  be  used  in  the 
definition  of  an  environment? 

Can  an  occupation  be  defined  as  an  environment? 

"Ian  an  event,  episode,  accident  or  ad  hoc  incident  be  defined  as 
an  environment? 

Can  a  hierarchical  description  such  as  a  specific  area  within  a 
room  within  a  building  be  defined  as  an  environment? 

To  what  hierarchical  depth? 

What  restrictions  apply? 

Can  multiple  descriptors  be  used  to  define  an  environment? 

How  many? 

Can  each  such  descriptor  be  an  ad  hoc  text? 

What  restrictions  apply? 

Is  there  an  intrinsic  limit  to  the  number  of  environments  that 
may  be  defined? 

Can  an  environment  be  defined  for  and  assigned  to: 

Any  agency  unit? 

Any  ad  hoc  selection  of  agency  units? 

Any  individual  person? 

Any  ad  hoc  selection  of  personnel? 

All  personnel  within  any  agency  unit? 

Any  ad  hoc  selection  of  personnel  within  an  agency  unit  or 
units? 

Personnel  having  a  specific  occupation? 

Personnel  working  in  more  than  one  occupation? 

Agency  units  and/or  personnel  involved  in  or  associated  with 
any  specific  event,  accident,  exposure  episode  or  other  ad 
hoc  user-defined  incidents? 


ASSOCIATED  DATA:  Provide  a  list  of  data  items  that  are 

intrinsically  solicited  relative  to  the  WORK  ENVIRONMENT 
topic  or  identifiers.  Include  any  necessary  description. 


UPDATE  CAPABILITY: 


Can  an  original  environment  definition  be  altered,  updated, 
expanded,  deleted  and  generally  manipulated? 

Does  the  update,  deletion  or  alteration  of  any  environment 
identifier  configuration  require  any  system  software  or 
hardware  modifications? 

Describe  all  necessary  modification  requirements  and  indicate 
by  whom  they  are  to  be  performed. 

Can  any  associated  intrinsic  data  items  be  entered,  updated  and 
generally  manipulated  by  the  user? 

Is  a  historical  record  of  <each/  some/  specific?  altered  data 
item  retained? 

Can  the  environment  to  agency  unit  and/or  personnel  relationship 
be  established,  altered  or  terminated  by  the  user  at  any 
time? 

Historical  retention  of  the  previous  relationship? 

Are  alterations  that  are  made  reflected  throughout  the  applicable 
elements  of  associated  functions? 

By  whom  can  the  above  tasks  be  done?  <general  user/system 
manager/system  implementor/ADP  professional? 

EDITING: 

Are  identifier  entries  and  changes  edited  for  content, 
construction  and  applicable  omission  or  duplication 
restraints  by  <entry  process/backyround  process/batch 
process/no  process?? 

Are  data  item  entries  and  changes  edited  for  content, 

construction  and  applicable  omission  or  duplication 
restraints  by  <entry  process/backyround  process/batcli 
process/no  process?? 

Describe  other  pertinent  edit  processes  or  considerations  that 
are  applied  to  these  data. 

FILING: 

Are  identifier  entries  and  alterations  filed  by  a  foreground/ 
background/batch?  process? 

Are  data  item  or  data  groups  filed  by  a  <f oreground/backy round/ 
batch?  process? 

Describe  any  additional  features  of  WORK  ENVIRONMENT  entry, 
editing,  update,  deletion  or  general  management  of  these 

functions . 


RETRIEVAL  &  DISPLAY:  Work  environment  identifiers/data  items 

Responses  to  the  following  questions  are  not  to  include  the 
capabilities  of  general  "Query",  "Data  Base"  or  "Report 
Generator"  functions  that  may  be  present  in  the  system.  Only 
capabilities  available  in  the  "normal"  entry,  edit,  update 
and  display  functions  are  solicited  here. 

Unless  otherwise  noted,  it  is  assumed  that  data  and  groups  of 
data  that  are  retrievable  in  the  manner  indicated  can  also  be 
displayed  to  the  user  in  that  manner  or  made  available  to  any 
other  applicable  task  concerned  with  the  agency  and  agency 
data. 

Can  any  environment  be  retrieved  individually? 

All  environments  used  by  a  specific  agency  unit? 

All  environments  assigned  to  a  specific  person? 

All  environments  for  a  specific  survey? 

Can  user-selection  of  individual  environments  be  accomplished 
from  the  above  group  retrieval? 

Can  retrieval  of  environments  be  accomplished  by  ambiguous 
identifier  entry? 

Can  retrieval  of  environments  be  accomplished  for  all 

environments  containing  an  incomplete  set  oE  descriptors; 
such  as,  retrieval  of  all  environments  containing  a  specific 
building  number  where  the  building  number  may  have  been  only 
one  element  of  a  description? 

Can  this  type  of  retrieval  be  done  using  any  number  or 
combination  of  user-specified  descriptors? 

Does  the  system  construct  a  selection  list  of  all  possible 

subject  candidates  for  an  incomplete  or  ambiguous  identifier 
entry? 

Is  multiple  selection  from  the  candidate  list  allowed  if 
applicable  to  the  task? 

Is  selection  of  all  entries  of  a  candidate  list  allowed  if 
applicable  to  the  task? 

Can  environment  retrieval  include  any  associated  agency  unit 
identification  data? 

Can  the  identification  data  of  persons  within  the  agency  unit 
and  who  are  associated  with  the  environment  also  be  included? 

For  applicable  tasks,  can  retrieval  optionally  include  pertinent 
identifiers  and/or  data  items  from  other  major  data  areas? 
Provide  a  list  of  topics  and  data  that  can  be  included. 
Identify  the  specific  tasks  or  functions  where  this  is 

allowed. 

Describe  any  additional  features  of  retrieval  of  WORK  EN V L ROMENT 
associated  system  elements. 


The  WORK  ENVIRONMENT  data  contains  or  directly  references: 

Agency  units  associated  with  an  environment? 

Personnel  assigned  to  an  environment? 

Survey  data  associated  with  the  environment? 

The  WORK  ENVIRONMENT  data  contains  or  directly  references  what 
other  primary  or  pertinent  data  areas  within  the  system? 
Describe. 
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SURVEY  FUNCTIONS  and  INFORMATION 


PURPOSE:  Describe  the  primary  objectives  that  the  system 

functions,  as  a  whole,  are  designed  to  provide,  achieve  or 
support  in  this  topic  area. 


IDENTIFIERS:  Include  explanations  or  comments  as  required. 

Can  local  conventions  for  indexing  or  referencing  be  used  to 
identify  a  survey? 

List  any  constraints  which  affect  the  configuration  of  a  survey 
reference . 

Is  there  an  intrinsic  limit  to  the  number  of  surveys  that  may  be 
defined? 

Can  a  survey  be  defined  for  and  associated  with: 

Any  environment? 

Any  number  of  environments? 

Any  type  of  environment? 

ASSOCIATED  DATA:  Provide  a  list  of  data  items  that  are 

intrinsically  solicited  relative  to  the  SURVEY  topic  or 
identifiers.  Include  any  necessary  description. 

UPDATE  CAPABILITY: 

Can  an  original  survey  data  content  be  altered,  updated, 
expanded,  deleted  and  generally  manipulated? 

Does  the  update,  deletion  or  alteration  of  any  survey  reference 
or  content  configuration  require  any  system  software  or 
hardware  modifications? 

Describe  all  necessary  modification  requirements  and  indicate 
by  whom  they  are  to  be  performed. 

Can  any  associated  intrinsic  data  items  be  entered,  updated  and 
generally  manipulated  by  the  user? 

Is  a  historical  record  of  <each/  some/  specific?  altered  data 
item  retained? 

Can  the  survey-to-environment  relationship  be  established, 
altered  or  terminated  by  tiie  user  at  any  time? 

Historical  retention  of  the  previous  relationship? 

Are  alterations  that  are  made  reflected  throughout  the  applicable 
elements  of  associated  functions? 

By  whom  can  the  above  tasks  be  done?  <general  user/system 
manager/system  implementor/ADP  professional? 
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EDITING: 

Are  identifier  entries  and  changes  edited  for  content, 
construction  and  applicable  omission  or  duplication 
restraints  by  <entry  process/background  process/batch 
process/no  process>? 

Are  data  item  entries  and  changes  edited  for  content, 
construction  and  applicable  omission  or  duplication 
restraints  by  <entry  process/background  process/batch 
process/no  process>? 

Describe  other  pertinent  edit  processes  or  considerations  that 
are  applied  to  these  data. 

FILING: 

Are  identifier  entries  and  alterations  filed  by  a  foreground/ 
background/batch>  process? 

Are  data  item  or  data  groups  filed  by  a  foreground/background/ 
batch>  process? 

Describe  any  additional  features  of  SURVEY  data  entry,  editing, 
update,  deletion  or  general  management  of  these  functions. 

RETRIEVAL  &  DISPLAY:  Survey  reference  iden ti f iers/data  items. 

Responses  to  the  following  questions  are  not  to  include  the 
capabilities  of  general  "Query",  "Data  Base"  or  "Report 
Generator"  functions  that  may  be  present  in  the  system.  Only 
capabilities  available  in  the  "normal"  entry,  edit,  update 
and  display  functions  are  solicited  here. 

Unless  otherwise  noted,  it  is  assumed  that  data  and  qroups  of 
data  that  are  retrievable  in  the  manne  '  indicated  can  also  be 
displayed  to  the  user  in  that  manner  o  made  available  to  any 
other  applicable  task  concerned  with  tl e  survey  and  survey 
data . 

Can  any  survey  be  retrieved  individually? 

All  surveys  for  a  specific  agency  unit? 

All  surveys  for  an  environment? 

Can  user-selection  of  individual  surveys  be  accomplished  from 
the  above  group  retrieval? 

Can  all  components  of  the  survey,  agent  sample  data,  material 
inventory  data  or  primary  survey  data  be  displayed 
selectively? 

For  applicable  tasks,  can  retrieval  optionally  include  pertinent 
identifiers  and/or  data  items  from  other  major  data  areas? 
Provide  a  list  of  topics  and  data  that  can  be  included. 


Describe  any  additional  features  of  retrieval  of  SURVEY 
associated  system  elements. 

The  SURVEY  data  contains  or  directly  references: 

Environments  associated  with  a  survey? 

Hazardous  agent  identification  associated  with  the  survey? 
Products  containing  hazardous  agents  associated  with  the 
survey? 


HAZARDOUS  AGENT  TABLE  and  FUNCTIONS 


PURPOSE:  Describe  the  primary  objectives  that  the  system 

functions,  as  a  whole,  are  designed  to  provide,  achieve  or 
support  in  this  topic  area. 

IDENTIFIERS:  Include  explanations  or  comments  as  required. 

Is  there  an  intrinsic  limit  to  the  number  of  agents  that  may  be 
defined? 

Can  each  agent  be  identified  by  actual  name? 

By  one  or  more  synonmous  names?  How  many  are  allowed? 

By  one  or  more  agent  number  or  code  configurations? 

By  any  user-defined  ad  hoc  identifier  scheme? 

ASSOCIATED  DATA:  Provide  a  list  of  data  items  that  are 

intrinsically  solicited  relative  to  the  HAZARDOUS  AGENT  topic 
or  identifiers.  Include  any  necessary  description. 

EXPOSURE  AND  MEDICAL  MONITORING  REQUIREMENTS  DATA: 

Does  the  system  maintain  the  association  between  an  agent  and  *-.he 
current  medical  examination  requirements  for  personnel 
exposured  to  or  association  with  the  agent? 

Does  the  system  maintain  other  pertinent  medical  information  for 
each  agent? 

List  the  other  medical  data  that  is  maintained. 

Are  hazardous  agent  concentration  and  exposure  limits  maintained? 
For  more  than  one  authority  such  as  PEL,  TLV,  N10SH  etc.? 

List  the  authorities  included. 

For  more  than  one  sampling  scale? 

For  TWA,  ACTION  LEVEL,  STEL  and  CEILING  limits? 

List  all  that  are  included. 

Can  agent  sampling,  handling  and  disposal  procedures  be 
maintained  for  each  agent  in  the  system? 

List  any  additional  attributes,  capabilities  or  elements  of 

consideration  that  are  applicable  to  the  agent  exposure  and 
medical  requirements  information. 

UPDATE  CAPABILITY: 

Can  the  original  agent  name  and/or  synonyms  be  updated? 

Can  any  associated  intrinsic  data  items  be  entered,  updated  and 
generally  manipulated  by  the  user? 

Is  an  historical  record  of  <each/somo/3pec i f ic>  altered  data 

item  retained? 
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Are  alterations  that  are  made  reflected  throughout  the  applicable 
elements  of  associated  functions? 

By  whom  can  the  above  tasks  be  done?  <general  user/system 
manager/system  implementor/ADP  professional? 

Does  the  update,  deletion  or  alteration  of  any  hazardous  agent 
identifier  configuration  or  data  item  require  any  system 
software  or  hardware  modifications? 

Describe  all  necessary  modification  requirements  and  indicate 
by  whom  they  are  to  be  performed. 

EDITING: 

Are  agent  identifier  entries  and  changes  edited  for  content, 
construction  and  applicable  omission  or  duplication 
restraints  by  <entry  process/background  process/batch 
process/no  process?? 

Are  data  item  entries  and  changes  edited  for  content, 

construction  and  applicable  omission  or  duplication 
restraints  by  <entry  process/background  process/batch 
process/no  process?? 

Describe  other  pertinent  edit  processes  or  considerations  that 
are  applied  to  these  data. 

FILING: 

Are  identifier  entries  and  alterations  filed  by  a  foreground/ 
background/batch?  process? 

Are  data  -tern  or  data  groups  filed  by  a  foreground/background/ 
batch?  process? 

Describe  any  cidditional  features  of  HAZARDOUS  AGENT  entry, 

editing,  update,  deletion  or  general  management  of  these 
functions . 

RETRIEVAL  &  DISPLAY:  Hazardous  Agent  identifiers/data  items 

Responses  to  the  following  questions  are  not  to  include  the 
capabilities  of  general  "Query",  "Data  Base"  or  "Report 
Generator"  functions  that  may  be  present  in  the  system.  Only 
capabilities  available  in  the  "normal"  entry,  edit,  update 
and  display  functions  are  solicited  here. 

Unless  otherwise  noted,  it  is  assumed  that  data  and  groups  of 
data  that  are  retrievable  in  the  manner  indicated  can  also  be 
displayed  to  the  user  in  that  manner  or  made  available  to  any 
other  applicable  task  concerned  with  the  agent  aid  agent 


Can  any  individual  agent  be  retrieved? 

By  name  entry? 

By  entry  of  a  synonym? 

By  entry  of  any  applicable  numeric  or  alphanumeric  code 
configuration? 

Can  retrieval  of  target  agent  data  be  accomplished  by  ambiguous 
name  or  synonym  identifier  entry? 

Does  the  system  construct  a  selection  list  of  all  possible 
subject  candidates  for  an  ambiguous  identifier  entry? 

Is  multiple  selection  from  the  candidate  list  allowed  if 
applicable  to  the  task? 

Is  selection  of  all  entries  of  a  candidate  list  allowed  if 
applicable  to  the  task? 

For  applicable  tasks,  can  retrieval  optionally  include  exposure 
limit  and  medical  requirement  information? 

Can  a  location  or  "in  use  by"  list  for  each  agent  be 
included? 

Provide  a  list  of  other  topics  and  data  that  can  be  included. 
Identify  the  specific  tasks  or  functions  where  this  is 
allowed . 

Describe  any  additional  features  of  retrieval  of  HAZARDOUS  AGENT 
associated  system  elements. 

The  HAZARDOUS  AGENT  data  contains  or  directly  references: 

Work  environments  containing  the  agent? 

Exposure  data  and  medical  health  care  requirements  for  the 
agent? 

The  HAZARDOUS  AGENT  data  contains  or  directly  references  what 
other  primary  or  pertinent  data  areas  within  the  system? 
Describe. 
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SYSTEM  MAINTENANCE: 


Are  routines  available  to  augment,  edit  and  otherwise  alter,  as 
necessary,  tables,  data  directories  and  other  intrinsic 
system  control  or  support  schema? 

Is  there  a  method  for  verification  of  application  data  file 

pointers,  count**  s,  cross-referencing  and  other  critical  file 
attributes? 

Describe  the  applicable  files  and  extent  of  verification. 

Can  the  verification  be  done  at  any  time? 

Is  there  a  method  for  the  automated  correction  of  filing 
discrepancies  available? 

Is  there  an  error  log,  trap  or  other  recording  of  the  occurrence 
of  a  software  error? 

Is  the  recording  available  at  any  time? 

Is  there  a  log  or  indicator  of  hardware  failure  occurrence  during 
critical  disc  filing  actions  or  other  operations  that  have 
the  potential  to  corrupt  the  system  routine  execution  or  data 
files? 

Are  maintenance  functions  available  to  archive  or  remove 

specified  out-of-date  or  historical  data  from  the  data  base? 

Describe  any  additional  features  of  SYSTEM  MAINTENANCE  associated 
operation. 


INDUSTRIAL  COMPONENT  OF  NOHIMS 


GLOSSARY 


Agency:  Any  organization  as  a  whole. 

Agent:  Any  chemical,  compound,  material,  product,  condition  or 

physical  phenomenon. 

Ambiguous  entry:  Refers  to  a  partial  or  incomplete  user  response 
to  a  system  request  for  subject  identification  or  selection 
information  such  that  more  than  one  subject  may  possess  the 
entered  configuration. 

Directory:  A  general  scheme  by  which  either  specific  or  ad  hoc 

subject  data  and  data  item  information  may  be  introduced, 
named,  defined,  identified,  retrieved  and  manipulated  in  the 
system  by  applicable  tasks. 

Environment:  Any  identifiable  physical  location,  area,  space, 

condition,  circumstance,  incident  or  episode  that  contains  or 
represents  a  real  or  potential  hazard  or  risk  when  inhabited 
by  or  associated  with  a  worker. 

Hazard:  Any  known  or  unknow  real  or  potential  risk  to  the 

general  short  or  long  term  health  of  a  worker. 

Identifier:  The  information  necessary  to  retrieve,  select  or 

make  known  a  unique  subject  or  data  group. 

Local:  Actual  "real  world"  or  "as  is  now  used"  conventions, 

configurations,  procedures  or  terminology. 

Personnel:  Any  civilian  or  military  employee,  contractor, 

visitor  or  other  person  that  is  under  the  authority  of  or  by 
circumstance  is  considered  to  be  within  an  area  of 
responsibility  of  an  agency. 

Retrieval:  To  identify,  select  and  make  available  the  desired 

subject  information. 

Subject:  The  intended  person,  place,  object,  topic,  data  item  or 

task  of  current  interest. 

Table:  A  stored  collection  and  arrangement  of  known  information 

on  one  or  more  subject  areas. 

Unit:  Any  unique  organizational  element  or  work  unit 

identifiable  within  an  agency. 


A-43 


COMPONENT  6 


If: 

If: 


DESCRIPTION  OF  SYSTEM  USERS 

FOR  EACH  NOHIMS  TEST  SITE: 

1.  Who  are  the  hands-on  clerical  users  of  NOHIMS?  (Examples:  recep¬ 
tionists,  medical  record  room  personnel,  and  data  entry  technicians.) 
Which  NOHIMS  options  do  they  use? 

Job  Title  and  NOHIMS 

Name  Function _  Options  Used 


a. 

b. 


c. 

d. 


2.  Who  are  the  hands-on  medical/professional  users  of  NOHIMS? 

(Examples:  MDs,  PAs,  NPs,  nurses,  occupational  health  technicians.) 
Which  NOHIMS  options  do  they  use? 

Job  Title  and  NOHIMS 

Name  Function  Options  Used 


a. 

b. 


c . 

d. 


3.  Who  are  the  hands-on  Industrial/professionnl  users  of  NOHIMS? 
(Examples:  industrial  hygienists  and  safety  specialists.) 

Which  NOHIMS  options  do  they  use? 

Job  Title  and  NOHIMS 

Name  Function  Options  Used 


a . 

b. 


c . 

d. 
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Who  are  the  hands-on  ancillary  users  of  NOHIMS?  (Examples:  labors 
tory,  radiology,  and  audiology  technicians  and  corpsmen.) 

Which  NOHIMS  options  do  they  use? 

Job  Title  and  NOHIMS 

Name  Function  Options  Used 

a . 

b. 

c . 

d. 


Who  are  the  hands-on  administrative  users  of  NOHIMS? 

(Examples:  clinic  directors  and  department  chiefs.) 

Which  NOHIMS  options  do  they  use? 

Job  Title  and  NOHTMS 

Name  Function  Options  Used 

a. 

b. 

c . 

d. 


Who  are  the  NOHIMS  system  manager (s)? 

Name  Job  Title  and  Function 

a. 

b. 

c . 


Who  are  the  other  hands-on  users  of  NOHIMS?  (Examples:  researcher 


Name 


Job  Title  and 
Pune  t i on 


NOHIMS 

Options  Used 
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USE  AND  USEFULNESS  OF  INFORMATION  RETRIEVAL  CAPABILITIES 


Standard  Reports 


1.  The  standard  reports  that  NOHIMS  produces  which  I  receive/use 
regularly  are 

Industrial  Hygiene  Survey  Report/ 

Report  of  Individual  Exposures/ 

Patient  Data  Sheet/ 

Medical  certification  report/ 

Monthly  Compliance  Report/ 

Navy  management  reports: 

Report  of  Occupational  Health  Services  (6260/1)/ 

Medical  Services  and  Outpatient  Morbidity  Report  (6300/1)/ 
Encounter  Report/ 

Patient  Summary/ 

Status  Report/ 

Flowcharts/ 

other: _ ___ _ / 

none  (go  to  9  if  none). 


2.  These  reports  are  used  in  my  work  to 

provide  direct  patient  care/ 
plan  workloads/ 
communicate  with  others/ 
prepare  required  reports/ 

other: _ _ _ _ _ / 

not  used. 


3.  The  reports  are  used 

daily/  quarterly/ 

weekly/  semi-annually/ 

semi-monthly/  annually/ 

monthly/  never. 


4.  The  information  produced  in  these  reports 

more  than  adequately  meets  my  needs/ 
adequately  meets  my  needs/ 
less  than  adequately  meets  my  needs/ 
is  not  relevant  to  my  work. 


5.  The  information  produced  in  these  reports  is 

very  useful/ 
somewhat  useful/ 
not  useful. 


6.  (Medical  users  only)  Spec  i  f  ical  1  v ,  in  ttie  day-to-day  provision 
of  medical  care,  the  standard  medical  reports  are 

very  useful/ 
somewhat  useful/ 
not  useful/ 


on  the  quality  of  medical 

I 

very  beneficial/ 

somewhat  beneficial/ 

t* 

no  effect/ 

V 

, 

somewhat  detrimental/ 

$ 

very  detrimental. 

8.  Additional  information/reports  I  would  find  helpful  include: 


User-defined  Information  Retrieval  Capabilities 

9.  The  user-defined  information  retrieval  capabilities  I  have  used  are 

Interactive  Flowcharts/ 

Report  Generator  runs/ 
interactive  query  function  in  OHS/ 
on-line  look-up/ 

other:  _ _ _ _  / 

none  (go  to  next  interview  section  if  none). 

10.  I  consider  the  ability  to  generate  user-defined  reports  to  be 


iv 

very  useful/ 

somewhat  useful/ 

not  useful. 

ii. 

I  generate  a  special  user-defined 

report 

i 

daily/ 

quarter] y/ 

weekly/ 

semi-annually/ 

«r. 

semi-monthly/ 

annually/ 

> 

monthly/ 

neve  r . 

V 

12. 

The  information  I  usually  retrieve 

using  specially 

generated 

t-k 

$ 

reports  is  used 

■S 

in  direct  patient  care/ 

for  resource  management/ 

$ 

to  assess  quality  of  care/ 

$ 

in  research/ 

& 

other : 

* 

?r 

13. 

(Medical  users  only)  In  the  day-to-day  provision  o 

f  medical 

v 

X 

the  user-defined  reports  are 

very  useful/ 

‘v 

'y 

somewhat  useful/ 

I 

not  useful/ 

not  used. 
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14.  (Medical  users  only)  The  effect  of  the  user-defined  reports  on 
the  quality  of  patient  care  has  been 

very  beneficial/ 
somewhat  beneficial/ 
no  effect/ 

somewhat  detrimental/ 
very  detrimental. 

15.  I  do  on-line  look-up/interactive  query  of  patient/worker  data 

often  during  the  day/ 
daily/ 

several  times  during  the  week/ 
weekly/ 

several  times  during  the  month/ 

other: _ / 

never . 

16.  I  do  on-line  look-up/interactive  query  with  the 

medical  component/ 
industrial  component/ 
both  components/ 
neither  component. 

17.  T  consider  the  ability  to  do  on-line  look-up/intcractive  query  of 
patient/worker  records  to  be 

very  useful/ 
somewhat  useful/ 
not  useful. 

18.  The  information  I  usually  retrieve  using  on-line  look-up/interactive 
query  is 

review  of  previous  patient  encounters/ 
lab  results/ 

patient-specific  exposures/ 
shop-specific  exposures/ 
survey-specific  information/ 

verify  or  look  up  administrative  information/ 
other : 
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SOFTWARE  QUALITY  ATTRIBUTES 

1.  Does  NOHIMS  allow  performance  of  all  required  tasks? 

What  functions  is  NOHIMS  required  to  perform? 

Does  NOHIMS  allow  performance  of  Identification  tasks? 

Does  NOHIMS  allow  performance  of  entry  tasks? 

Does  NOHIMS  allow  performance  of  review  tasks? 

Does  NOHIMS  allow  performance  of  editing  tasks? 

Does  NOHIMS  allow  performance  of  information  retrieval  tasks? 
Does  NOHIMS  allow  performance  of  system  maintenance  tasks? 

2.  Is  NOHIMS  a  reliable  system? 

Is  the  data  retrieval  consistent? 

Can  the  user  corrupt  the  database  intentionally  or  uninten¬ 
tionally? 

Can  the  system  resolve  extraneous  input? 

3.  What  error  recovery  procedures  does  NOHIMS  have? 

What  system  functions  aid  in  recovering  data  if  an  error 
occurs  or  if  the  system  crashes? 

What  inherent  abilities  does  NOHIMS  have  to  insure  the 
integrity  of  the  database,  such  as  Monitor  in  the  medical 
component  which  does  "housekeeping"  chores  before  halting? 

What  system  features  prevent  program  and  data  "crashes"? 

4.  What  back-up  procedures  are  required  to  prevent  data  loss? 

How  often  should  the  database  be  copied  to  disk? 

How  often  should  the  database  be  copied  to  magnetic  tape? 

What  procedures/functions  are  used  to  restore  the  database 
from  a  back-up? 

How  easy  is  it  to  restore  the  database  from  a  back-up? 

5.  What  features  make  the  source  program  code  efficient? 

How  much  of  the  system  memory  does  NOHIMS  require  to  operate? 
What  features  minimize  this  requirement? 

6.  How  portable  and  hardware  independent  is  NOHIMS? 

Can  NOHIMS  be  configured  on  a  portable  system? 

Is  a  particular  hardware  configuration  required  to  operate 
NOHIMS? 

7.  How  maintainable  is  the  NOHIMS  software? 

Does  NOHIMS  require  ongoing  software  support? 

Is  system  support  required  to  maintain  the  integrity  of  the 
database? 
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OPERATIONAL  CHARACTERISTICS 
User  Friendly  Features 

1.  How  well  does  NOHIMS  present  Its  operational  capabilities  to  the 
user? 

While  selecting  system  options,  is  the  screen  display 
clear  and  helpful? 

Are  the  system  prompts  well  worded  and  informative?  Are 
they  easy  to  understand? 

Are  data  displays  and  reports  presented  in  easily  readable 
and  understood  formats? 

Are  there  messages  from  NOHIMS  that  tell  the  user  how  the 
system  interpreted  the  entries? 

Are  there  messages  from  NOHIMS  that  tell  the  user  what  the 
the  system  is  doing,  such  as  "Please  wait  while  filing"? 

2.  Is  NOHIMS  "menu  driven"  at  all  selection  levels? 

Are  the  option  menu  displays  well  organized  and  easy  to  read? 

3.  What  user  on-line  assistance  functions  does  NOHIMS  have? 

Can  the  user  ask  for  help  text  at  system  selection  prompts? 

At  what  selection  levels  does  NOHIMS  have  help  text? 

Is  it  easy  to  ask  the  system  for  help  text? 

Is  there  more  than  one  level  of  detail  of  help  text? 

Is  the  help  text  easily  readable  and  understood?  Ts  the 
help  text  concise? 

Does  the  help  text  contain  examples? 

Is  the  help  text  specific  to  the  NOHIMS  application?  Does 
it  need  to  be  specific  to  the  NOHIMS  application? 

Can  the  help  text  messages  be  changed  without  programming 
intervention? 

Are  there  other  on-line  assistance  functions? 

Are  there  supporting  job  aids  and  operations  manuals? 

A.  What  error  diagnostic  features  and  debugging  aids  does  NOHIMS  have? 

Is  there  an  error  log,  trap,  or  other  recording  of  the 
occurrence  of  a  software  error? 

Is  there  an  error  log  or  other  indicator  of  hardware  failure 
occurrence  during  critical  filing  actions  or  other  operations 
that  could  potentially  corrupt  the  system  routine  execution 
or  data  f lies? 

What  information  is  recorded  in  the  error  log(s)?  How  is 
the  log  organized? 
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How  accessible  is  the  information  in  the  error  log(s)?  Is  it 
available  at  any  time?  to  any  user? 

How  long  is  the  error  log  maintained  by  NOHIMS?  Can  old  or 
corrected  errors  be  deleted  from  the  log  without  programming 
intervention?  Who  can  delete  them? 

Can  a  user  document  errors  obtained  while  using  NOHIMS  in  a 
file  for  later  review  by  a  system  manager? 

Can  system  functions  be  tested  without  affecting  the  live 
database? 

5.  What  database  manager  utilities  does  NOHIMS  have? 


Data  Manipulation  Tasks 

6.  What  is  the  average  entry  time  per  input  form? 

7.  What  are  the  add,  save,  change,  and  delete  procedures? 

8.  Does  NOHIMS  have  a  search  in  context  capability? 

What  are  the  limitations  on  its  ability  to  search  in  context? 

Can  searches  be  performed  on  segments  of  a  patient/worker 
name? 

Does  the  system  have  an  alphabetic  look-up  function  for 
directory  items? 

9.  What  are  the  general  filing  procedures  for  NOHIMS? 

Are  they  the  same  for  both  the  medical  and  industrial 
components? 

0.  Can  data  and  routines  by  downloaded  to  magnetic  tape? 

How  is  this  accomplished? 
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ASSESSMENT  OF  USER  FRIENDLINESS 

1.  It  was 

very  easy/ 
somewhat  easy/ 
somewhat  difficult/ 
very  difficult/ 

for  me  to  learn  to  use  NOHIMS. 

j~]  Have  not  learned  to  use  NOHTMS  (then  go  to  next 

interview  section). 

2 .  I  am 

very  confident/ 
somewhat  confident/ 
somewhat  unsure/ 
very  unsure/ 

of  my  ability  to  work  with  NOHIMS. 

3.  It  is 

easier/ 

somewhat  easier/ 
not  different/ 
somewhat  more  difficult/ 
more  difficult/ 

to  use  NOHIMS  than  other  automated  systems  I  have  used. 
r~~l  Not  used  other  systems. 

4.  Please  rate  the  following  features  of  NOHIMS  in  terms  of  their 
helpfulness  in  using  NOHTMS. 

Very  Somewhat  Not 

lie  lj)_f u  1  He  I  p  f  t ll  IleJ  pful 

a.  Screen  displays  _ _  _  _ 

b.  System  prompts/menus  _  _  _ 

c.  System  messages  _  _  _ 

d.  Help  text /ass i stance 

functions  _  _ _  _ 

e .  Report  f o rma t s  _  _  _ 

f.  Techniques  for  looking 

up  an  individual  _  _  _ 

g.  Agency  unit  look-up  _  _ _ 

h.  Environment  look-up  _  _ 

i.  Survey  data  look-up  _ 

j  .  Hazardous  agent  look-up 

k.  Directory  item  look-up 
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Improvements  I  would  like  to  see  to  make  NOHIMS  easier  to  use  includ 


Overall,  I  feel  that  NOHIMS  is 

very  user  friendly/ 
somewhat  user  friendly/ 
somewhat  user  unfriendly/ 
very  user  unfriendly. 


COMPONENT  It 

INFORMATION  RETRIEVAL  CAPABILITIES 

1.  What  system  options  in  the  medical  component  of  NOHIMS  are  involved 
with  information  retrieval? 


Display  Registration  Data/ 
Display  Medical  Data/ 

Print  Medical  Data/ 

COSTAR  Report  Generator/ 
ad  hoc  interactive  query/ 
other : 


2.  What  are  the  main  functions  and  features  of  each  of  the  options 
involved  with  information  retrieval  in  the  medical  component  of 
NOHIMS? 

Registration:  Display  Registration 

Can  the  patient  to  be  displayed  be  identified  with  an 
ambiguous  entry? 


Can  the  patient  be  identified  by  name?  by  social  security 
number?  by  unit  number? 

Are  patient  names  searched  by  phonetics? 

Can  the  display  of  registration  items  be  formatted  in  any 
manner  desired? 

Can  changes  be  made  to  the  registration  record  while  in 
this  option? 

Describe  any  additional  features  of  this  option. 

Display  Medical  Data 

Can  patients  for  whom  data  are  to  be  displayed  be  identified 
with  ambiguous  entries? 

Can  patients  for  whom  data  are  to  be  displayed  be  identified 
by  name?  by  social  security  number?  by  unit  number? 

Does  the  patient  to  be  displayed  need  to  be  identified  for 
each  display  request? 

Can  all  the  data  for  a  given  encounter  be  retrieved  in  a 
report  format? 

Does  NOHIMS  display  a  list  of  encounters  entered  for  the 
patient? 

What  is  the  format  for  the  Encounter  Report?  Can  this  format 
be  changed  without  programming  intervention? 


What  data  elements  are  included  in  the  Encounter  Report? 
Which  of  t^eir  associated  elements  (results,  statuses,  text, 
etc.)  are  displayed? 

Can  the  user  request  the  display  of  a  single  data  item? 


Are  the  registration  data  displayed  with  the  encounter  data? 


A-54 


Can  the  user  select  to  display  an  encounter  on  a  particular 
date? 

Can  the  user  select  to  display  the  most  recent  encounter? 
the  first  encounter?  the  nth  encounter?  from  any  encounter, 
the  previous  encounter? 

Can  the  user  request  the  display  of  all  encounters  that 
contain  a  particular  item? 

Can  the  user  request  the  display  of  more  than  one  encounter 
with  the  same  request  (e.g.,  the  last  N  encounters)? 

Can  the  user  select  the  encounters  to  be  displayed  by  the  type 
of  encounter?  site  of  the  encounter?  provider  of  care  for 
the  encounter?  characteristics  of  patients?  other  nondate- 
related  criteria? 

Will  the  system  produce  reports  that  summarize  data  across 
encounters?  Can  the  encounters  to  be  summarized  be  specified? 

What  is  the  format  of  these  summary  reports?  Can  this  format 
be  altered  without  programming  intervention? 

What  data  elements  are  included  in  the  summary  reports?  Which 
of  the  associated  data  (results,  statuses,  text,  etc.)  are  also 
displayed? 

Can  a  single  data  item  or  set  of  data  items  be  displayed  across 
encounters?  Can  the  user  select  which  data  item  or  which  set 
of  data  items? 

Can  the  user  choose  to  limit  the  associated  data  items  that 
are  displayed  in  the  summary  reports? 

Can  the  ability  to  display  reports  be  restricted  to  certain 
devices?  to  certain  classes  of  users?  to  certain  users? 

Is  there  help  text  for  the  display  medical  data  procedures? 

Can  the  registration  data  display  be  reviewed  while  in  this 
option? 

Can  the  information  in  the  displays  be  edited  while  in  this 
option? 

Can  both  hardcopy  and  softcopy  reports  be  obtained? 

Describe  any  additional  features  of  this  module. 

Print  Medical  Data 

Will  NOHIMS  automatically  print  reports  for  all  patients 
scheduled  to  be  seen  on  a  given  day?  Which  reports  can  be 
printed? 

Can  the  user  specify  which  reports  for  which  patients  are 
to  be  printed? 

Can  reports  be  printed  for  those  patients  that  were  entered 
in  a  particular  batch?  within  the  last  N  days?  Which  reports 
can  be  printed  in  this  manner? 


Can  the  user  specify  the  order  of  print  of  the  reports? 

Can  the  printing  of  reports  be  interrupted?  restarted? 

Can  the  user  indicate  which  device  to  print  the  reports  on 
in  order  to  free  terminals? 

Can  the  requests  for  report  printouts  be  stored,  to  be  used 
again  at  a  later  date? 

Can  the  ability  to  print  medical  reports  be  restricted  to 
certain  devices?  to  certain  classes  of  users?  to  certain  users 

Is  there  help  text  for  the  print  medical  data  procedures? 

Describe  any  additional  features  of  this  module. 

COSTAR  Report  Generator 

Can  listings  of  data  items  or  the  data  associated  with  data 
items  (results,  statuses,  text,  etc.)  be  produced? 

Can  tabulations  of  data  items  or  the  data  associated  with 
data  items  (results,  statuses,  text,  etc.)  be  produced? 

Can  reports  be  generated  for  every  patient  in  the  database? 
for  every  encounter  in  the  database? 

Can  subsets  of  patients  be  selected  for  reports?  Can  patients 
be  selected  on  patient  characteristics?  encounter  character¬ 
istics?  dates  of  encounters?  other  criteria? 

Can  subsets  of  encounters  be  selected  for  reports?  Can 
encounters  be  selected  on  patient  characteristics?  encounter 
characteristics?  dates  of  encounters?  other  criteria? 

What  is  the  format  of  the  listings  and  tabulations  generated 
by  NOHIMS?  Can  this  format  be  altered  without  programming 
intervention? 

What  does  a  user  need  to  know  about  the  directory  codes  in 
order  to  use  the  report  generator? 

Can  the  user  define  selection  criteria  for  individual  data 
items  such  as  last,  most  recent,  number  of,  etc.? 

Are  there  any  restrictions  on  the  data  items  that  can  be 
listed  at  any  one  time?  tabulated  at  any  one  time? 

Will  NOHIMS  generate  2-way  tables?  3-way  tables?  4-way 
tables? 

Can  individual  items  be  seiected  for  reports?  Can  classes  of 
items  be  selected  for  reports?  Can  items  be  selected  by 
associated  data  such  as  status,  presence/absence  of  free 
text,  presence/absence  of  results? 

Will  NOHIMS  compute  percentages  for  the  tabulation  tables? 

Can  the  user  specify  the  denominator?  Can  more  than  one 
denominator  be  defined? 


Will  NOHIMS  compute  deviations  from  the  mean  for  the  tabula¬ 
tion  tables? 


Will  NOHIMS  compute  chi  square  values  for  the  tabulation 
tables?  calculate  t  statistics?  perform  analysis  of  variance 

Does  NOHIMS  compute  actuarial  statistics  such  as 
survival  rates,  morbidity  rates,  or  mortality  rates? 

Does  NOHIMS  produce  graphic  representations  of  data  produced 
in  reports  such  as  histograms  and  trend  lines? 

What  time-saving  features  does  the  report  generator  have  to 
shorten  the  search  through  the  database? 

Can  data  in  reports  be  printed  in  patient  name  alphabetic 
order? 

Can  data  in  reports  be  printed  in  encounter  date  order? 

Can  the  user  create  a  set  of  report  specifications? 

Can  the  report  specifications  be  stored  for  later  use? 

Can  the  report  specifications  be  edited?  Can  these  be 
saved  under  a  new  name? 

Can  the  user  select  which  report  specification  is  to  be 
altered  or  must  each  specification  be  edited  or  accepted? 

Can  report  specifications  be  deleted? 

Can  a  list  of  available  report  specifications  be  displayed? 

Can  a  user  select  to  run  a  report  from  the  report  specifi¬ 
cations  stored  in  NOHIMS? 

Can  a  report  specification  file  be  renamed? 

Are  there  any  limits  on  what  a  report  specification  file  can 
be  named? 

Does  NOHIMS  keep  track  of  when  changes  were  last  made  to  a 
report  specification  file? 

Does  NOHIMS  store  data  generated  by  the  report  runs  for 
future  printing/use? 

Can  files  stored  during  report  runs  be  deleted? 

Can  a  user  specify  a  particular  time  on  a  particular  date 
to  run  a  report? 

Can  more  than  one  report  be  run  at  a  time? 

Can  the  report  runs  be  linked  to  run  one  after  the  other? 

Does  running  a  report  tie  up  any  terminals/printers? 

Can  both  hardcopy  and  softcopv  output  be  produced? 

Does  NOHIMS  have  an  interactive  query  capability? 

Is  there  help  text  for  the  report  generator  procedures? 

Can  mailing  labels  be  generated  hv  the  svstem?  Can  they  he 
printed  in  zip  code  order?  alphabetic  order? 

Can  mailing  labels  he  printed  for  n  subset  of  patients? 

Describe  any  additional  features  of  this  module. 
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3.  What  are  the  Information  retrieval  functions  in  the  industrial 
component  of  NOHIMS? 

ad  hoc  interactive  query/ 
report  generation/ 
display  of  data/ 
printing  of  data/ 

other:  _ 

4.  What  are  the  main  functions  and  features  of  the  ad  hoc  interactive 
query  function  in  the  industrial  component  of  NOHIMS? 


Syntax 

Does  the  query  utilize  a  custom  syntax  to  describe  the  desired 
sequence  and  topics  to  be  retrieved? 

Indicate  the  identifiers  and  data  item  areas  that  are  accessible 
via  the  query  syntax. 

Agency  identifiers? 

Agency  data  items? 

Personnel  identifiers? 

Personnel  data  items? 

Environment  Identifiers? 

Environment  data  items? 

Hazardous  Agent  identifiers? 

Hazardous  Agent  Table  data  items? 

Survey  identifiers? 

IHS  Survey  and  Occupational  Hazard  Data  Sheet  data  items? 

Identifiers  (Include  explanations  or  comments  as  required.) 

Indicate  which  topic  identifiers  are  directly  selectable  via 
the  query  syntax. 

Agency  units? 

Environments? 

Personnel? 

Hazardous  Agents? 

Surveys? 

Can  as  many  topic  identifiers  as  desired  be  specified  in  an 
ad  hoc  fashion? 

Does  the  query  have  the  full  capability  for  identification  and 
selection  of  each  topic  that  is  provided  in  the  normal  topic 
area  functions? 

Can  the  query  assume  an  "all  available"  set  of  topic  identi¬ 
fiers  at  any  topic  area  identifier  selection  point? 

Are  there  any  topic  area  identifiers  that  cannot  be  specified 
via  the  query  operation? 


Data  Items 


Can  the  user  select  specific  data  items  for  each  applicable 
topic  area? 
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Can  a  data  item  be  subjected  to  user-specified  conditional 
testing? 

Can  testing  include  comparison  to  a  given  numeric  value? 

Can  testing  include  comparison  to  a  given  numeric  interval  ? 
Can  testing  be  done  for  the  presence  of  a  data  item? 

Can  testing  be  done  for  the  absence  of  a  data  item? 

Can  testing  include  comparison  to  a  given  literal  value? 

Can  testing  include  a  search  of  the  data  item  content 
for  a  given  single  of  multi-word  literal? 

Can  testing  include  comparison  to  an  associated  table  of 
values  where  applicable  to  the  data  item? 


Process 

Is  the  construction  of  a  query  syntax  set  an  interactive 
process? 

Can  a  query  syntax  set  be  filed  and  reused  whenever  required? 

Is  the  execution  of  a  query  syntax  set  a  foreground  process? 

Can  the  output  information  of  a  query  task  be  directed  to 
either  a  terminal  screen  or  a  printer  as  required? 

Is  the  query  operation  available  to  the  general  user  if  per¬ 
mitted  by  the  system  security  attributes  for  the  user? 

Describe  any  additional  retrieval  features  of  the  OUF.RY  function 
or  operation. 

5.  Please  see  the  interview  section  on  System  Description  for  questions 
on  the  industrial  component's  display  and  printing  of  data  and 
generation  of  standard  reports. 
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COMPONENT  12 


I 

SECURITY  FEATURES 

1.  What  are  the  features  of  the  medical  component  of  NOHIMS  that 
maintain  the  confidentiality  of  patient  information? 

Are  system  users  identified  in  some  form  by  NOHIMS? 

Is  there  a  user  identification  sequence  to  sign  onto 
NOHIMS?  Is  the  identification  sequence  echoed  such  that 
it  is  displayed  or  may  be  viewed  at  the  sign-on  device? 

Can  the  display  of  the  identification  sequence  be  masked 
or  overstruck? 

Can  access  to  various  options  be  restricted  by  device? 
by  class  of  user?  by  user? 

Can  options  and  special  functions  be  protected  by  a  password? 

Does  NOHIMS  report  security  breaches?  disconnect  users 
who  breach  or  attempt  to  breach  security? 

Can  users  no  longer  qualified  to  access  NOHIMS  be  deleted 
from  the  access  list? 

Does  NOHIMS  have  an  automatic  time  out  for  unattended  terminals? 

Are  data  fields  masked?  Are  patient  names  kept  separately 
from  data  files? 

Do  data  collection  forms  contain  confidentiality  warnings? 

Do  reports  generated  by  NOHIMS  contain  confidentiality 
warnings? 

Can  occupational  health  information  be  accessed  from  the 
medical  component  of  NOHIMS? 

Can  medical  data  be  accessed  from  the  industrial  component 
of  NOHIMS? 

Who/what  controls  the  security  features? 

2.  What  are  the  security  features  of  the  industrial  component  of  NOHIMS? 
Terminal  Device  Security 

It  is  assumed  that  access  to  the  computer  system  via  a  local 
or  remote  terminal  device  is  controlled  by  the  established 
conventions  of  the  operating  system.  The  following  questions 
are  directed  only  to  the  application-supported  security  func¬ 
tions  that  provide  control  over  terminal  device  and  personnel 
access  to  the  application  capabilities. 

T ermln al  Devi ce  Access 

Can  a  user's  access  to  specific  functions  be  determined  and 
delimited  by  the  particular  terminal  device  or  communication 
access  line  in  use?  Describe. 

Can  the  device  access  be  altered  as  required? 

Can  the  associated  function  access  for  the  device  be 
altered  as  required?  Ry  whom? 
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Is  there  a  unique  identification  sequence  assigned  to  each 
individual  user? 

Does  the  user  identification  delimit  access  to  specific 
functions?  Describe. 

Is  the  identification  sequence  echoed  such  that  it  is 
displayed  or  may  be  viewed  at  the  sign-on  device? 

Can  the  identification  sequence  be  altered  as  required? 

Can  the  associated  functional  access  be  altered  as  required? 

Is  there  an  access  control  required  to  execute  the  system 
maintenance  functions  that  define  or  alter  the  terminal 
and/or  user  identification  access  attributes? 

Describe  any  additional  features  of  SECURITY-associated 
system  operation. 
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ADEQUACY  OF  SECURITY  FEATURES 

1.  In  my  opinion,  the  sign  on/off  security  procedures  are 

very  adequate/ 
somewhat  adequate/ 
somewhat  inadequate/ 
very  inadequate/ 

tc  prevent  unauthorized  persons  from  accessing  NOHIMS. 

2.  In  my  opinion,  the  various  security  levels  (by  device,  by  user 
classification,  through  passwords  for  specific  options)  are 

very  adequate/ 
somewhat  adequate/ 
somewhat  inadequate/ 
very  inadequate/ 

to  prevent  persons  from  accessing  areas  of  NOHIMS  for  which  they 
are  not  authorized. 

3.  In  my  opinion,  the  confidentiality  warnings  on  input  and  output 
documents  are 

very  adequate/ 
somewhat  adequate/ 
somewhat  inadequate/ 
very  inadequate/ 

to  maintain  the  confidentiality  of  patient/worker  data. 

4.  The  security  protection  features  provided  by  NOHIMS  are 

fully  utilized/ 
loosely  utilized/ 
ignored/ 
bypassed . 

5.  In  general,  the  security  protection  provided  by  NOHIMS  is 

insuf  f icient/ 
somewhat  insufficient/ 
somewhat  sufficient/ 
sufficient . 

6.  If  insufficient  or  somewhat  insufficient,  the  areas  of  protection 
which  are  lacking  include: 


7.  In  general,  the  security  protection  provided  by  NOHIMS  is 

unnecessary/ 
somewhat  unnecessary/ 
somewhat  necessary/ 
necessary . 
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If  unnecessary  or  somewhat  unnecessary,  the  areas  which  should  be 
removed  or  changed  include: 
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SOFTWARE  SUPPORT  REQUIREMENTS 

1.  What  and  how  many  support  personnel  are  required  to  maintain  the 
NOHIMS  software? 

_  ADP  personnel: 

_  managers/ 

_  operators/ 

_  programmers/ 

_  system  analysts/ 

_  outside  consultants/ 

_  vendors 

2.  What  functions  must  be  performed  by  the  support  personnel? 

system  back-ups/ 

investigating  and  correcting  system  errors/ 

directory  updates/ 

software  updates/ 

archival  of  records  to  tape/ 

changing  report  parameters 

3.  What  is  the  estimated  amount  of  support  manhours  required  per 
month  to  maintain  the  system? 
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HARDWARE  SUPPORT  REQUIREMENTS 

1.  What  and  how  many  support  personnel  are  required  to  maintain  the 
NOHIMS  hardware? 

_  ADP  personnel: 

_  managers/ 

_  operators/ 

_  programmers/ 

_____  system  analysts/ 

_  outside  consultants/ 

_ __  vendors 

2.  What  functions  must  be  performed  by  the  support  personnel? 

periodic  maintenance/ 
system  back-ups/ 
repack  disks/ 
repairs 

3.  What  is  the  estimated  amount  of  support  manhours  required  per 
month  to  maintain  the  system? 
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AVAILABLE  SYSTEM  SUPPORT 

1.  What  kind  of  system  support  is  available  for  initial  training  of 
NOHIMS  users? 

NOHIMS  training  module/ 
outside  consultants/ 
on-site  trainers/ 
off-site  trainers/ 
system  managers/ 
audio-visual  packages/ 
outside  training  seminars/ 
users  groups/ 
other : 


2.  What  kind  of  system  support  is  available  for  ongoing  and  update 
training  of  NOHIMS  users? 

NOHIMS  training  module/ 

outside  consultants/ 

on-site  trainers/system  managers/ 

off-site  trainers/ 

audio-visual  packages/ 

outside  training  seminars/ 

users  groups/ 

other:  _  _ 


3.  What  kind  of  system  support  is  available  for  the  NOHIMS  hardware? 
outside  consultants/ 

in-house  consul t ants/ prog ramme rs/ana 1 ys ts/ 

technical  "hotline"  to  _  _  _ 

on-site  support /system  managers/other _ _ _ _ 

outside  training  seminars/ 

users  groups/ 

other: 


A.  What  kind  of  system  support  is  available  fo>"  the  NOHIMS  software? 

NOHIMS  svstem  maintenance  module/ 
outside  consultants/ 

in-house  ronsu 1 tant s/programmers/ ana  1  vs  ts / 
technical  "hotline"  to 

on-site  support /svstem  managers/other 
outside  training  seminars/ 
users  groups/ 


What  kind  of  documentation  and  job  aids  are  there  that  support  system 
operation? 

documentation  for  data  entry 

Specify: _ / 

documentation  for  data  retrieval 

Specify: _ / 

documentation  for  system  maintenance 

Specify:  _ / 


job  aids  that  support  documentation 
Specify: 


/ 
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SYSTEM  SCENARIOS  TO  MAINTAIN  THE  SYSTEM 

1.  What  prime  time  system  maintenance  functions  must  be  performed 
during  the  day  on  a  daily  basis? 

be  certain  that  Monitor  is  running  in  the 
background  before  entering  data/ 
review  error  logs/ 
investigate  common  or  new  errors/ 

other: _ _ 

2.  What  system  maintenance  functions  must  be  performed  during  the 
off-shift  on  a  regular  basis?  How  often  must  these  tasks  be 
performed? 

system  back-ups  on  a  daily/weekly/monthly  basis/ 
recreate  alphabetic  directory  on  a  daily/weekly/ 
monthly/as  needed  basis/ 
other : 


3.  How  often  must  patient  files  be  archived  to  tape? 

monthly/ 
quarterly/ 
annually/ 
as  needed 
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ORGANIZATIONAL  REQUIREMENTS 

1.  What  requirements  are  there  for  users  of  NOHIMS  to  have  MUMPS 
programming  skills? 

none  required/ 

minimal  amount  of  knowledge  required/ 
moderate  amount  of  knowledge  required/ 
extensive  knowledge  required. 

2.  What  requirements  are  there  for  system  managers  of  NOHIMS  to  have 
programming  skills? 

none  required/ 

minimal  amount  of  knowledge  required/ 
moderate  amount  of  knowledge  required/ 
extensive  knowledge  required. 

3.  What  requirements  are  there  for  system  managers  of  NOHIMS  to 
comprehend  NOHIMS  source  code? 

none  required/ 

minimal  amount  of  comprehension  required/ 
moderate  amount  of  knowledge  required/ 
extensive  knowledge  required. 

4.  Describe  in  full-time  equivalents  (FTEs)  the  staff  required  to 
operate  a  NOHIMS  installation. 

_ _  FTE(s)  of  data  collection  personnel 

_  FTE(s)  of  data  entry  personnel 

_  FTE(s)  of  system  managers 

_  FTE(s)  of  administrative  personnel 

_____  FTE(s)  of  support  personnel 

5.  Describe  the  requirements  for  the  configuration  of  the  installation 
area. 

What  are  the  electrical/power  source  requirements? 

What  are  the  lighting  requirements? 

What  are  the  communications  requirements? 

What  are  the  heating/cooling  requirements? 

What  are  the  space  and  room  dimension  requirements? 

What  furniture/equipment  is  required  (excluding  system 
hardware)  such  as  desks,  chairs,  and  file  cabinets? 
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SUITABILITY  OF  NOHIMS  TO  NAVY  INFORMATION  PROCESSING  NEEDS 

1.  The  features/capabilities  of  NOHTMS  that  make  it  especially 
suitable  to  Navy  information  processing  needs  are 

the  required  information  is  collected: 
personnel  data/ 

hazardous  materials  characteristics/ 
presence  of  hazardous  materials/ 
data  on  health  of  workers: 
illness  and  injuries/ 
sick  leave/absenteeism/ 
routine  examinations/ 
test  and  procedure  results/ 
medical  histories/ 
mortality  data/ 

individual  exposures/exposure  history/ 
data  on  accidents/incidents/ 
occupational  histories/ 

other: _ _ _ _ / 

data  can  be  retrieved  in  the  required  formats: 
tables  of  hazardous  materials/ 
lists  of  workers  with  exposures/ 

lists  of  workers  requiring  physical  examinations/ 
medical  encounter  reports/ 
medical  summary  reports/ 
management  reports/ 

other: _ _ _ _ / 

data  can  be  manipulated  in  required  ways: 
number  of  surveys  conducted/ 
number  of  individuals  exposed  to  hazard/ 
number  of  examinations  conducted/ 
number  of  laboratory  tests  done/ 
number  of  radiographs  done/ 
number  of  asbestos  examinations  conducted/ 
list  of  those  with  ordered  but  unresulted  tests/ 
other: _ _ _ _ _ / 

other: 


2.  My  assessment  of  the  suitability  of  NOHIMS  to  Navy  information 
collection  needs  is  that  NOHIMS  is 

very  suitable/ 
somewhat  suitable/ 
somewhat  unsuitable/ 
very  unsuitable. 

3.  My  assessment  of  the  suitability  of  NOHIMS  to  Navy  information 
retrieval  needs  is  that  NOHTMS  is 

very  suitable/ 
somewhat  suitable/ 
somewhat  unsuitable/ 
very  unsuitable. 


4.  My  assessment  of  the  suitability  of  N0H1MS  to  Navy  information 
manipulation  needs  is  that  NOHIMS  is 

very  suitable/ 
somewhat  suitable/ 
somewhat  unsuitable/ 
very  unsuitable. 


5.  Areas  in  which  NOHIMS  could  be  changed  to  make  it  more  suitable 
to  Navy  information  processing  needs  include 

collect  additional  information 

Specify:  _ _ / 

imp rove /ere ate  new  retrieval  capabilities 

Specify: _ / 

improve/create  new  manipulation  capabilities 

Specify: _ / 

other : 


6 .  Overall,  my  assessment  of  the  adequacy  of  NOHIMS  for  Navy  information 
processing  needs  is  that  NOHIMS  is 

very  adequate/ 
adequate/ 

somewhat  adequate/ 
somewhat  inadequate/ 
inadequate/ 
very  inadequate. 
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ASSESSMENT  OF  SYSTEM  PERFORMANCE 

1.  NOHIMS  has  given  no/some/many  problems  in  the  area  of 

reliability/ 

downtime/ 

communication  lines/ 
man-machine  interface/ 
other : 


2.  A  noticeable  (to  the  user)  failure  happens  about  _ _ _ _/ 

_  and  that  number  has  been 

improving/ 

steady/ 

getting  worse. 

3.  The  number  of  failures/errors  for  NOHIMS  is 

acceptable/ 
somewhat  acceptable/ 
somewhat  unacceptable/ 
unacceptable . 

4.  When  there  is  heavy  usage  of  the  computer  system,  then  there  will  be 

a  noticeable  slowdown/ 
an  annoying  slowdown/ 
a  terrible  slowdown/ 
no  effect. 

5.  Data  entry  is 

never/ 

rarely/ 

occasionally/ 

often/ 

delayed  by  system  response  time. 

6.  The  time  required  to  obtain  a  display  of  data  is  usually 

fast/ 

somewhat  fast/ 
somewhat  slow / 
slow. 

7.  When  a  NOHIMS  failure  occurs,  it  affects  the  day-to-day  provision 
of  medical  care  because 

work  procedures  must  be  changed/ 

reports  usually  used  in  care  are  not  available/ 

on-line  look-ups  cannot  be  done/ 

medical  charts  are  held  up  in  data  entry/ 

survey  data  are  held  up  in  cntrv/ 

other:  _ _ _  _  _  _ _ _ _ _ / 

no  ef feet . 
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8.  When  a  NOHIMS  failure  occurs,  it  affects  the  administration  of  the 
occupational  health  unit  because 

work  procedures  must  be  changed/ 
reports  usually  used  are  not  available/ 
on-line  look-ups  cannot  be  done/ 
medical  charts  are  held  up  in  data  entry/ 
survey  data  are  held  up  in  entrv/ 
data  entry  gets  backlogged/ 

other: _ _ _ _ 

no  effect. 

9.  NOHIMS  has 

no/ 

one  or  two/ 
a  few/ 
several / 
many/ 

major  "bugs"  in  the  software  that  affect  system  performance. 

These  are: 


10.  T  have  used  or  been  exposed  to  NOHIMS  for _ months. 
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YOUR  STRUCTURED  APPRAISAL  OF  THE  PERFORMANCE  OF  THE 
NAVY  OCCUPATIONAL  HEALTH  INFORMATION  MANAGEMENT  SYSTEM  (NOlilMS) 


Contained  in  the  following  pages  are  22  statements  reflecting 
possible  attitudes  or  opinions  that  users  of  NOHIMS  might  hold.  You 
are  being  asked  to  carefully  read  each  of  these  statements  and  then  to 
place  an  "X"  in  the  blank  that  most  nearly  reflects  your  opinion  of 
NOHIMS,  indicating  the  extent  to  which  you  agree  or  disagree  with  each 
statement.  PLEASE  EXPRESS  AN  OPINION  ON  EACH  STATEMENT  EVEN  IF  YOU 
HAVE  NEVER  THOUGHT  ABOUT  THIS  SUBJECT  BEFORE  IN  JUST  THIS  WAY. 


The  intent  of  this  short  exercise  is  to  systematically  explore 
what  your  subjective  attitudes  and  opinions  are  concerning  the  impact 
of  NOHIMS  on  your  department.  Your  responses  will  remain  anonymous 
and  will  be  used  only  in  the  aggregate  to  provide  a  composite  picture 
of  the  benefits  that  have  accrued  from  NOHIMS  in  your  department. 
Thank  you  for  your  cooperation  and  valued  assistance. 


SITE: 


APPRAISAL  OF  THE  PERFORMANCE  OF  NOHIMS 


Strongly  Neutral  Strongly 

Agree  Agree  Opinion  Disagree  Disagree 

1.  Worker/patient-related 
information  is  more 
accessible  and  available 

more  quickly  with  NOHIMS.  _ 

2.  As  a  result  of  NOHIMS, 

I  am  able  to  do  a  better 
job. 


3.  The  performance  of  NOHIMS 
falls  short  of  what  I 
expected . 


4.  I  could  never  go  back  to 
using  the  old  manual 
record  system  now  that  I 
have  been  using  NOHIMS. 


5.  NOHIMS  catches  more  human 
errors  than  the  old  manual 
system  did. 


6.  In  my  opinion,  NOHIMS 
should  not  have  been 
implemented  at  this 
activity . 


7.  I  rarely  have  to  wait  for 
necessary  worker/patient 
information  because  the 
NOHIMS  system  is  down. 


8.  In  general,  NOHIMS  is 
better  than  the  old  manual 
system  of  record  keeping. 

9.  NOHIMS  has  some  major 
problems  that  need 
correction . 

10.  If  there  were  budget  cuts 
at  this  activity,  T 
would  rather  see  other 
services  that  I  need  cut 
before  I  lost  NOHIMS. 


A  _  7C 
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11. 


12. 


13. 


14. 


15. 


16. 


17. 


19. 


20. 


NOHIMS  has  "goofed"  up 
worker/patient  records 
more  times  than  I  care 
to  remember. 


I  truly  feel  that  the 
quality  of  care  has  been 
improved  as  a  result  of 
NOHIMS. 


From  an  administrative 
point  of  view,  NOHIMS 
provides  timely  data  for 
making  management  deci¬ 
sions  that  were  not 
available  with  the  pre¬ 
vious  manual  system. 


Scheduling  and  staffing 
patterns  have  been  im¬ 
proved  since  the  advent 
of  NOHIMS. 


NOHTMS  does  not  benefit 
me  much  personally. 


Worker/patient  satisfac¬ 
tion  seems  to  be  running 
higher  since  NOHIMS  was 
introduced . 


I  can  see  how  NOHIMS  can 
be  a  boon  to  other  users. 


18.  With  NOHIMS,  I  am  able  to 
get  more  done  in  a  day. 


The  records  produced  by 
NOHIMS  are  more  amenable 
to  review  and  better 
meet  Navy  standards. 


The  confidentiality  of 
the  worker's/patient's 
record  is  more  vulner¬ 
able  with  NOHIMS  than 
it  was  with  the  manual 
system . 


Strongly 

Agree 


Agree 


Neutral  Stronglv 

Opinion  Pi sagree  Disagree 
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Strongly  Ncutrnl  Strongly 

Agree  Agree  Opinion  Pi sagree  Disagree 


21.  I  don't  care  much  what 

NOHIMS  costs  to  operate, 
we  need  It  to  handle  our 
workload  efficiently. 


22.  If  NOHIMS  were  to  be 
taken  out,  I  would  be 
willing  to  make  a  rea¬ 
sonable  effort  to  get 
it  back  in  service. 


The  purpose  of  the  following  two  questions  is  to  provide  cl assi fication 
information  for  the  statistical  analysis  of  responses  to  the  questionnaire. 
Please  mark  all  categories  that  apply  to  you. 

23.  I  am  a  system  developer 

user 

24.  My  function  is  clerical 

medical : 

professional 
anci llary 

industrial : 

hygienist/safetv 

specialist 

work  center 
supervisor 

administrative 


other : 
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APPROPRIATE  SCENARIOS  FOR  SYSTEM  TESTING 

1.  Should  NOHIMS  features  and  functions  be  tested  using  the  examples 
contained  in  the  operational  manuals,  using  contrived  test  data, 
live  data,  or  some  combination  thereof? 

2.  What  features  and  functions  of  NOHTMS  should  be  operat iona 1 1 y  tested 
to  be  certain  that  NOHIMS  can  perform  expected  tasks? 

Should  a  hazardous  agent  table  be  created?  What  data 
are  required  in  a  hazardous  agent  table? 

Should  data  from  an  industrial  survey (ies)  be  entered 
into  NOHIMS?  What  data  are  gathered  in  an  industrial 
survey? 

Should  data  from  a  physical  examination (s)  be  entered 
into  NOHIMS?  What  data  are  gathered  in  a  physical 
examination? 

Should  one/several  of  the  following  be  generated  by 
NOHIMS?  What  data  are  required  in  NOHIMS  and  what 
parameters  must  be  known  in  order  to  generate  these 
items? 

Notification  of  individual  exposures 
List  of  patients  requiring  physical 
examinations 
Patient  Data  Sheet 
Patient  Summary 
Encounter  Report 
Flowcharts 

Reports  for  the  6260/1  management  report 
Medical  certification  report 

Should  one  or  more  user-defined  reports  be  generated  by 
NOHIMS?  What  should  be  the  content  of  these  reports? 

What  information  is  required  to  be  in  NOHTMS  in  order 
to  generate  these  reports? 

Should  one  or  more  queries  into  the  database  be  performed? 

What  should  be  the  content  of  the  queries? 

What  other  features  and  functions  should  be  operationally 
tested?  What  information  is  required  in  order  to  perform 
these  tests? 

3.  How  will  the  results  of  these  tests  be  evaluated? 

What  criteria  will  be  used  to  evaluate  the  performance 
of  NOHIMS? 

What  level  of  performance  will  be  considered  satisfactory? 

How  many  times  will  a  given  test  be  performed?  by  how 
many  different  users? 
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MEDICAL  MONITORING  AND  CARE  GOALS/ASSESSMENT  OF  HOW  WELL  MEDICAL  MONITORING 
AND  CARE  GOALS  ARE  BEING  MET 

23A  1.  It  is  ray  understanding  that  the  specific  goals  for  NOHIMS  in  the 

area  of  medical  monitoring  and  care  are/were  to  improve 

quality  of  care: 

v  patient  management: 

diagnostic  tests/ 
database  acquisition/ 
treatment  planning/ 
problem  identification/ 

feedback  to  physician  regarding  achievement 
of  desired  outcomes/ 

patient  compliance  with  physician  orders  because 
of  comprehensiveness/continuity  of  care/ 
quality  of  care  review  procedures/ 
research  information  collection/ 
training  activities/ 
record  accuracy/ 

earlier  diagnosis  of  abnormal  conditions/ 
earlier  notification  of  patient  abnormalities/ 
communication/ 
automated  medical  testing/ 

access  to  care: 

patient  follow-up/ 
appointment  scheduling/ 
record  contents/ 
record  availability/ 
visit  registration/ 
medical  reports/ 

resource  utilization: 

health  manpower  utilization/availability: 
medical  -  technical  personnel/ 
clerical  personnel/ 
use  of  paramedical  personnel/ 
all  personnel/ 
patient  services: 

fewer  unnecessary  visits/ 

fewer  redundant  laboratory  tests/ 

better  referral/ 

management  aspects  of  health  care: 

improve  management  and  operations  of  the  facility  by: 
provision  of  management  with  information  and 
analytical  tools  for: 

utilization  review  procedures/ 
manpower  scheduling/ 
budgeting  and  planning,/ 
long-range  manpower  planning/ 
long-range  facility  planning/ 
regi  onal /Navv-wi  de  health  ['fanning/ 
administrative  reports/ 


compliance  with  monitoring  programs/Navv  sot  standards  of  care: 
periodic  physical  examinations/ 
protective  equipment/ 
asbestos  surveillance  program. 

2.  I  consider  NOHIMS  in  its  present  state  to  be  meeting  these  medical 
monitoring  and  care  goals 

very  well/ 
somewhat  well/ 
somewhat  not  well/ 
not  well. 

3.  The  specific  goals  NOHIMS  is  not  meeting  very  well  are 

improvement  in  the  quality  of  care/ 
improvement  in  access  to  care/ 
improvement  in  resource  utilization/ 
improvement  in  management  and  operations/ 
improvement  in  compliance  with  monitoring  programs/ 
other : 


4.  The  reasons  that  NOHIMS  is  not  meeting  these  goal(s)  are 

NOHIMS  lacks  essential  function(s) 

Specify:  _ 

feature (s)  are  not  implemented 
Specify: 

feature (s)  are  not  implemented  well 
Specify: 
other : 


5.  The  goals  that  have  been  only  partially  achieved  are 

improvement  in  quality  of  care/ 

improvement  in  access  to  care/ 

improvement  in  resource  utilization/ 

improvement  in  management  and  operations/ 

improvement  in  compliance  and  monitoring  programs/ 

other : 


6 .  The  reasons  that  NOHIMS  has  only  partially  achieved  those  goal(s)  are 

NOHIMS  lacks  essential  function(s) 

Specify: _ _  _  _  _  _  _ / 

feature  (s)  are  not  implemented 

Specify:  _  _  __  _  / 

feature (s)  are  not  implemented  we  I  1 

Specify: _  _  / 

other : 


7.  The  effect  of  NOHIMS  has  been  to 
increase /main  tain /decrease 
the  quality  of  care. 


/ 

/ 

/ 


23A 
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The  effect  of  NOHIMS  has  been  to 
increase /main tain /decrease 
the  access  to  care. 

The  effect  of  NOHIMS  has  been  to 
increase /main tain /decrease 
resource  utilization. 

The  effect  of  NOHIMS  has  been  to 
increase /main tain /decrease 
compliance  with  monitoring  programs. 

The  effects  of  NOHIMS  generally  have  been  because  of 

increased  patient  care  services  provided/ 
more  appropriate  services  provided/ 
improved  follow-up  of  patients  with  abnormal 
findings  or  tests/ 

improved  communication  between  departments/ 
increased  availability  of  the  medical  record/ 
more  accurate  medical  records/ 

availability  of  patient-specific  summary  reports/ 

availability  of  on-line  look-up  of  patient-specific  data/ 

availability  of  user-defined  reports/ 

improved  manpower  scheduling/ 

improved  patient  compliance/ 

improved  quality  of  care  review  procedures/ 

earlier  diagnosis  and  notification  of  problems/ 

improved  appointment  scheduling/ 

other: _ _  _ _ _ _ _ _ _ 

Since  NOHIMS  was  implemented,  communication  between  industrial 
hygienists  and  medical  personnel  lias 

improved/ 

been  maintained/ 

deteriorated . 

If  communication  has  changed,  this  is  general lv  because  of 

availability  of  reports  generated  bv  NOHIMS/ 
less  need  for  direct  commun i cat  ion/ 
more  accurate  or  complete  data/ 

other:  _ _ _ _ _ _ _ 

(Industrial  users  only)  Since  NOHIMS  was  implemented,  commun I cati on 
between  industrial  hygienists/safotv  specialists  and  work  center 
supervisors  has 

imp  roved/ 
been  maintained/ 


15. 


(Industrial  users  only) 
generally  because  of 


If  communication  lias  changed,  this  is 


availability  of  reports  generated  by  NOUIMS/ 
less  need  for  direct  communication/ 
more  accurate  or  complete  data/ 
other : 


16. 


The  effect  of  the  availability  of  an  accurate  medical  record  on  the 
quality  of  patient  care  has  been 


very  beneficial/ 
somewhat  beneficial/ 
no  effect/ 

somewhat  detrimental/ 
very  detrimental. 


17. 


The  effect  of  the  availability  of  an  individual's  exposure  history 
at  the  time  of  the  physical  examination  has  been 


very  beneficial/ 
somewhat  beneficial/ 
no  effect/ 

somewhat  detrimental/ 
very  detrimental. 


18.  The  effects  of  NOHIMS  on  medical  monitoring  and  care  have  been 
evaluated  through  measurements  which  are 


subjective  judgment 

Specify  who:  _ 

counting/ 


objective  measures  such  as  surveys  and  questionnaires/ 
other: 


no  measurements  done. 


19.  Evaluation  measurement  methods  used  include 


examination  of  the  medical  record  for  accuracy  and 
completeness/ 

examination  of  the  medical  record  for  appropriateness/ 

checking  of  the  diagnostic  test  pattern/ 

assessment  of  patients'  response  to  treatment/ 

assessment  of  patient  compliance/ 

assessment  of  quality  of  care  review/ 

evaluation  of  research  contributions/ 

evaluation  of  missed  appointments/ 

evaluation  of  timeliness  of  physical  examinations/ 
evaluation  of  availability  of  medical  record/ 
evaluation  of  manpower  utilization/ 
evaluation  of  time  taken  for  specific  tasks/ 
checking  appropriateness  of  laboratory  tests  done/ 
checking  adequacy  of  protective  equipment  issued/ 
checking  adequacy  of  follow-up  on  abnormal  findings 
or  tests/ 
other : 
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23A  20.  Results  of  measurements  conducted  are 


(NOTE:  Questions  on  usefulness  of  reports  are  found  In  Component  7, 

"USE  AND  USEFULNESS  OF  INFORMATION  RETRIEVAL  CAPABILITIES.") 
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INFORMATION  REQUIRED  FOR  NAVY  LEGAL  PURPOSES 

1.  The  legal  purposes  for  which  data  stored  in  NOHIMS  could  be 
used  are 

workers'  compensation  determinations/ 
tort  claims  actions/ 

Veterans  Administration  disability  procedures/ 

Navy  medical  boards/ 
other : 


2.  The  types  of  data  required  for  the  above  legal  purposes  are 

protection  used/ 
hazardous  exposures/ 
physical  examination  data/ 
job  histories/ 
medical  histories/ 
illness  and  injury  data/ 
mortality  data / 
demographic  data/ 
other : 


Specific  data  elements  required  are 


To  be  useful  in  Navy  litigations,  the  data  stored  in  NOHIMS  must  be 
supported  by 

the  industrial  hygiene  survey  stored  in _ _ / 

the  paper  medical  record  stored  in  the  patient's  chart/ 
elsewhere/ 

the  medical  data  entry  document  stored  in  the  patient's 
chart /elsewhere/ 

both  the  paper  medical  record  and  the  data  entry  document 
stored  in  the  patient's  chnrt/el  sewliere/ 
a  physician's  signature  on  the  paper  medical  record/ 
computer-generated  report/data  entry  document/ 
an  industrial  hygienist's  signature  on  the  industrial 
hygiene  survey/computer-generated  report/ 
procedures  of  the  ordinary  course  of  business/ 
other: 


To  be  useful  in  Navy  litigations,  the  data  stored  in  NOHIMS  must  be 
formatted 

in  any  manner/ 


The  kinds  of  information  about  NOHIMS  that  are  required  to  prove 
the  legal  foundation  of  NOHIMS  include 

description  of  computer  hardware/physical  plant/ 
description  of  data  entry  procedures/ 
description  of  software: 

features  that  assure  input  accuracy/ 

features  that  protect  the  integrity  of  the  database/ 

security  features/ 
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ASSESSMENT  OF  HOW  WELL  NOHIMS  MEETS  NAVY  LEGAL  NEEDS 

1.  What  obligations  does  the  Navy  have  to  respond  to  discovery  requests 
and  subpoenas  for  NOHIMS-gene rated  data?  Is  it  more  likely  that  the 
paper  medical  record  will  be  requested  or  subpoenaed? 


2.  a.  Could  NOHIMS  standard  operating  procedures  be  construed  as 

meeting  the  requirements  that  records  admissable  as  evidence 
in  legal  proceedings  be  made  in  the  ordinary  course  of  business? 


b.  If  not,  why  not? 


3.  a.  Are  there  adequate  witnesses  who  can  provide  legal  foundation 
for  computer-stored  records  (i.e.,  witnesses  with  relevant 
educational  and  occupational  background  who  can  testify  to 
the  type  of  computer  used,  the  physical  plant,  procedures  used, 
software  integrity,  and  security  features)? 


b.  Who,  specifically,  could  currently  provide  this  function? 


c.  Would  their  testimony  on  the  characteristics  of  NOHIMS  be 
adequate  to  prove  legal  foundation? 


4.  Would  a  sampling  of  the  NOHIMS  database  be  accepted  as  representative 
of  the  entire  database? 


What  is  your  assessment  of  the  effect  of  NOHIMS  on  the  number  of 
Navy  legal  claims,  if  any,  and  why? 

decrease,  because  of  reduction  in  errors/improved  patient 
care/improved  compliance  with  Navy/OSHA  standards/ 
proof  of  compliance  with  Navy/OSHA  standards/ 

other:  _ 

increase,  because  of  easier  access  to  records/proof  of  non- 
compliance  with  Navy/OSHA  standards/highlighting  of  errors/ 

other:  _ 

no  effect/ 

no  opinion/cannot  say 

What  is  your  overall  assessment  of  the  adequacy  of  NOHIMS  for  use 
as  a  legal  database? 

very  adequate/ 
adequate/ 

somewhat  adequate/ 
somewhat  inadequate/ 
inadequate/ 
very  inadequate 
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APPROPRIATE  SCENARIOS  FOR  TESTING  OF  LEGAL  INTERROGATORIES 

1.  Describe  in  detail  some  typical  legal  cases  bandied  by  the  Navy 
legal  department . 


2.  What  specific  information  would  be  required  from  the  N0H1MS  database 
for  these  specific,  types  of  cases? 


3.  What  specific  time  frame  is  usually  required  for  obtaining  data 
for  these  typical  cases? 
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NOHIMS  AS  AN  AID  TO  EPIDEMIOLOGIC  RESEARCH 

1.  The  epidemiologic  research  functions  that  I  see  NOHIMS  being  useful 
for  include 

identifying  populations  at  ri sk/cohorts/ 
identifying  workers  exposed,  exposure  levels,  and 
length  of  exposure/ 

determining  medical  effects  of  exposures/ 
detecting  disease  trends/outbreaks/ 

identifying  common  risk  factors  among  exposed  workers/ 

other: _ _ _ _ _ _ • 

2.  The  kinds  of  data  required  for  these  investigations  include 

demographic  data/ 

worker  exposure  histories,  including  type  of  hazard/ 
degree  of  severity/time  of  exposure/duration  of 
exposure/ 

worker  occupational  histories/ 
worker  medical  histories/ 
physical  examination  data: 

presenting  complaints/ symptoms/ 
test  results/ 
diagnoses/ 
mortality  data / 

other: _ _ _ _ _ • 

3.  The  features/capabilities  of  NOHIMS  that  will  be  useful  in 
epidemiologic  research  include 

cross-referencing  ability/ 

ability  to  analyze  data  at  varying  levels  (individual, 
selected  groups,  or  population)/ 
reference  tables/ 

ad  hoc  information  retrieval  capabilities/ 

other:  _ . 

A.  My  assessment  of  the  adequacy  of  NOHIMS  for  conducting  epidemiologic 
research  is  that  NOHIMS  is 

very  adequate/ 
adequate/ 

somewhat  adequate/ 
somewhat  inadequate/ 
inadequate/ 
very  inadequate. 

5.  If  NOHIMS  is  not  at  least  adequate,  the  limitations/problems  that 
I  see  with  NOHIMS  are 

inability/limited  ability  to  manipulate  database 

Specify: _ _ _ _ _ _ _ _ / 

required  data  are  not  collected 

Specify:  _ _ _ _ _ _ _ _ _ / 

data  are  collected  improperly/not  standardized 

Specify: _ _ _  _  _ _ / 


other : 
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USES  IN  ADMINISTRATIVE  FUNCTIONS /ASSESSMENT  OF  USEFULNESS  OF  NOHIMS  IN 
ADMINISTRATIVE  FUNCTIONS 


28A  1. 


28A  2. 
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The  administrative  functions  that  l  see  NOHIMS  being  useful  for 
include 

determining  environmental  differential  pay  decisions/ 

increasing  standardization  of  reports/ 

increasing  standardization  of  data  collection  forms/ 

reducing  paperwork/ 

generating  administrative  reports/ 

providing  timely  and  perpetual  access  to  administrative  data/ 

manpower/resource  planning/ 

time  and  motion  studies/ 

maintaining  equipment  1 ists/ 

managing  inspection  requirements/ 

other:  _ _ _ _ 

The  kinds  of  data  required  for  these  functions  include 

hazard  exposures/ 
service  utilization  data/ 
manpower/resource  utilization  data/ 

other:  _ _ _ _ _ _ 

The  features/capabilities  of  NOHIMS  that  will  be  useful  in 
administrative  functions  include 

standard  report  generation  capabilities/ 
on-line  look-up/interactive  query  functions/ 
ad  hoc  report  generation  capabilities/ 


My  assessment  of  how  NOHIMS  has  affected  the  amount  of  required 
paperwork  is  that  NOHIMS  has 

greatly  increased  the  amount  of  paperwork/ 
somewhat  increased  the  amount  of  paperwork/ 
no  effect/ 

somewhat  decreased  the  amount  of  paperwork/ 
greatly  decreased  the  amount  of  paperwork. 

It  in  my  opinion  that  in  terms  of  standardizing  reports  and  forms 
NOHIMS  has  iiad 

a  beneficial  effect/ 
a  somewhat  beneficial  effect/ 
no  effect/ 

a  somewhat  detrimental  effect/ 
a  detrimental  effect. 

My  assessment  of  the  usefulness  of  having  timely  and  perpetual 
access  to  administrative  data  with  NOIUMS  is  that  it  is 

use  ful / 

somewhat  useful/ 
somewhat  not  useful/ 
not  useful. 
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APPLICABILITY  OF  NOHIMS  TO  OTHER  NAVY  INDUSTRIAL  SITES 

1.  How  do  the  Information  processing  needs  of  the  other  Navy  industrial 
sites  that  will  be  receiving  NOHIMS  differ  from  the  information 
processing  needs  of  the  test  sites?  Are  the  two  test  sites  repre¬ 
sentative  of  the  other  sites? 


/ 

/ 


2.  Can  NOHIMS  be  adapted  to  a  variety  of  Navy  industrial  settings  and 
sites  such  as  air  rework  facilities,  shipyards,  and  public  works 
centers?  Are  there  aspects  of  NOHTMS  that  would  make  it  unsuitable 
for  any  of  these  various  environments? 


3.  Is  NOHIMS  applicable  to  Navy  industrial  settings  of  varying  sizes? 
What  limitations/requirements  does  NOHIMS  have  that  relate  to  the 
size  of  the  application  environment? 


b.  What  organizational  changes  are  required  at  a  new  site  in  order  for 
NOHIMS  to  perform  successfully?  For  example,  what  changes  to  normal 
operating  methods  and  procedures  are  required?  What  changes  in 
terminology?  Will  this  present  problems  at  other  Navy  industrial 
sites? 


5.  What  changes  in  the  patterns  of  information  exchange  and  communica¬ 
tion  will  NOHIMS  cause  at  a  new  site?  Will  this  present  problems 
at  other  Navy  industrial  sites? 


no  difference/ 

different  data  collection  requirements 

Specify:  _  _ 

different  reporting  requirements 

Specify:  _ 

other  di f ference (s) 

Specify :  _  _ 
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FEATURES  THAT  MAKE  NOHIMS  FLEXIBLE  AND  ADAPTABLE 

1.  What  features  of  the  med leal  component  of  NOHTMS  make  it  flexible 
and  adaptable  to  the  various  needs  of  other  Navy  industrial  sites? 

Is  NOHIMS  directory  driven?  Can  codes  be  added  or  deleted 
from  the  directory? 

Can  parameters  for  the  codes  be  set  and/or  changed?  What 
parameters  can  be  set?  Which  of  these  can  be  changed? 

Can  data  other  than  directory  codes  be  entered  in  a  patient 
record? 

Is  there  a  limit  to  the  kinds  or  amounts  of  information 
that  can  be  coded/entered? 

Can  registration  entry,  medical  encounter  entry,  and  lab 
results  entry  be  done  in  any  order?  at  the  same  time? 
at  different  times? 

Can  the  entry  sequences  for  registration  and  for  medical 
encounter  entry  be  altered? 

Can  an  already  existing  numbering  scheme  be  used  for 
identifying  patient  records?  Can  the  social  security 
number  be  used  as  the  unit  number? 

Can  a  patient  be  looked  up  by  either  name,  unit  number,  or 
social  security  number? 

Is  there  a  choice  as  to  how  codes  can  be  entered  in  order 
to  balance  ease  of  data  entry  with  ease  of  use  by  providers? 

Can  standard  report  formats  and  content  be  specified  and/ 
or  altered? 

Can  the  user  create  ad  hoc  reports?  in  any  format  desired? 
with  any  content  desired?  Does  the  system  have  an  inter¬ 
active  query  function? 

Can  the  above  choices  or  changes  be  made  without  requiring 
programming  intervention?  Are  there  system  maintenance 
functions  which  perform  these  tasks? 

What  requirements  are  there  for  encounter  and  laboratory 
results  input  documents? 

What  features  make  the  medical  component  easy  to  learn 
and  use? 

Does  NOHIMS  have  on-line  assistance  functions?  Is  it 
menu  driven? 

What  supporting  documentation  and  job  aids  are  there  to 
help  the  user? 

What  system  support  is  required  to  maintain  the  system? 

Is  this  support  readily  available? 

Can  a  variety  of  hardware  con  I i gurat  i ons  support  the  system? 
Can  NOHTMS  accommodate  a  variety  of  terminal /cursor  types? 
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What  features  of  the  Industrial  component  of  NOHIMS  make  it  flexible 
and  adaptable  to  the  various  needs  of  other  Navy  industrial  sites? 

Is  NOHIMS  directory  driven?  Can  codes  be  added  or  deleted 
from  the  directory? 

Can  parameters  for  the  codes  be  set  and/or  changed?  What 
parameters  can  be  set?  Which  of  these  can  be  changed? 

Can  data  other  than  directory  codes  be  entered  in  a  file? 

Can  user-specific  identifiers  be  defined  and  used? 

Can  a  worker  be  identified  by  either  name,  social  security 
number,  or  local  employee  number/pay  number? 

Can  data  other  than  directory  codes  be  entered  in  a 
worker  record? 

Is  there  a  choice  as  to  how  codes  can  be  entered  in  order 
to  balance  ease  of  data  entry  with  ease  of  use  by 
industrial  hygienists? 

Is  there  a  limit  to  the  kinds  or  amounts  of  data  that 
can  be  entered  into  the  files? 

Can  organizational  structures  be  defined  to  suit  the  site? 

Can  a  variety  of  entities  be  defined  as  environments? 

Can  local  conventions  for  indexing  or  referencing  be  used 
to  identify  a  survey? 

Can  tables  of  hazards  and  medical  care  standards  be 
defined /altered? 

Can  standard  report  formats  and  content  be  specified 
and/or  altered? 

Can  the  user  create  ad  hoc  reports?  in  any  format  desired? 
with  any  content  desired?  Does  the  system  have  an  inter¬ 
active  query  function? 

Can  the  above  choices  or  changes  be  made  without  requiring 
programming  intervention?  Are  there  system  maintenance 
functions  which  perform  these  tasks? 

What  requirements  are  there  for  input  documents? 

What  features  make  the  industrial  component  easy  to  learn 
and  use? 

Does  NOHIMS  have  on-line  assistance  functions?  Is  it 
menu  driven? 

What  supporting  documentation  and  job  aids  are  there  to 
help  the  user? 

What  system  support  is  required  to  maintain  the  system? 

Is  this  support  readily  available? 

Can  a  variety  of  hardware  configurations  support  the  system? 

Can  NOHIMS  accommodate  a  variety  of  terminal /cursor  types? 
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IMPLEMENTATION  PROCESS  AT  TEST  SITES 
Implementation  Process 

1.  (NHRC  system  developers  and  test  site  administrators  only)  Who  was 
involved  in  the  implementation  of  NOHTMS  at  the  (your)  test  site(s)? 
What  degree  of  involvement  did  each  of  these  people  have? 

a .  e . 

b.  f . 

c.  g. 

d .  h . 

2.  (NHRC  system  developers  and  test  site  administrators  only)  Tn  what 
areas  of  the  implementation  were  each  of  these  people  involved?  What 
total  amount  of  time  did  each  of  these  people  spend  on  the  implemen¬ 
tation  of  NOHIMS? 


a . 

e  . 

b. 

f. 

c . 

fi¬ 

d. 

ll. 

3.  In  what  areas  of  the  implementation  were  you  directly  involved?  What 
total  amount  of  time  did  you  spend  on  the  implementation  of  NOHIMS? 


4.  (NHRC  system  developers  and  test  site  administrators  only)  What  steps 
were  involved  in  implementing  NOHIMS  at  the  (your)  test  sito(s)? 


3.  From  your  perspective,  what  problems  were  encountered  during  the 

implementation  of  NOHIMS?  How  were  these  problems  resolved/handled? 


6.  Was  staff  morale  affected  by  the  installation  of  NOHTMS? 
Was  this  effect  a  positive  or  negative  one? 

Was  the  effect  temporary? 


i 
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Operational  Procedures 

7.  What  are  the  current  data  collection  procedures  for  NOHIMS?  What 
changes  were  required  in  previous  standard  data  collection  proce¬ 
dures  in  order  to  accommodate  NOHIMS? 

Who  collects  the  data? 

Who  verifies  the  data? 

At  what  points  in  the  process  are  data  collected? 


8.  What  are  the  current  data  entry  procedures  for  NOHIMS  data? 
Who  enters  the  data? 


What  is  the  backlog  for  data  entry? 


9. 


What  are 
Who 


the  current  data  retrieval 
requests  retrieval  of  data 


procedures? 
from  NOHIMS? 


Who  retrieves  the  data  from  NOHIMS? 

How  long  does  it  take  to  get  the  requested  information? 

10.  What  are  the  current  uses  of  reports/data  generated  by  NOHIMS? 

What  changes  were  required  in  previous  standard  operating  procedure 
in  order  to  utilize  the  reports/data  generated  by  NOHIMS? 

Are  reports/computer-generated  data  available  to  the 
physician  when  he/she  sees  the  patient? 


Do  the  data  collection  instruments  support / repl ace /exist 
in  addition  to  the  previously  used  forms/records? 

Does  the  computer-generated  report  support/ repl ace/exi st 
in  addition  to  the  paper  medical  record? 


Are  NOHIMS  reports  used  to  identifv  workers  requiring 
physical  examinations? 


Are  NOHIMS  reports  used  to  monitor  compliance  with  Navv 
standards? 

Is  NOHIMS  used  to  product' /col  1  cot  data  for  management  reports? 
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Operational  Procedures  (Cont . ) 

11.  What  is  the  hardware  configuration  at  the  (your)  test  site(s)? 

What  type  and  how  many  terminals  are  there? 

What  type  and  how  many  printers  are  there? 

What  type  of  communications  equipment  is  used? 

What  type  of  processor  is  used? 

Where  are  these  devices  located? 

Are  remote  terminals  and  printers  used  on  a  regular  basis? 

12.  What  physical  security  features  have  been  implemented  at  the  (your) 
test  site(s)? 

Are  there  cipher  locks  on  doors? 

Is  there  a  log  book  for  people  entering  the  computer  room? 

Is  there  a  record  of  batch  programs? 

13.  (NHRC  system  developers  and  test  site  administrators  only)  Is  NOHIMS 
a  development  of  a  previous  automated  system  at  the  test  site(s)? 
replacement  of  a  previous  automated  system?  supplement  to  an 
existing  manual  system?  replacement  of  a  manual  system? 

a  completely  new  data  collection  and  processing  system? 

14.  What  problems  do  you  encounter/are  encountered  in  day-to-day  opera¬ 
tions  of  NOHIMS?  How  are/were  these  problems  resolved/handled? 


Assessment  of  Adaptability  of  NOHIMS  to  Needs  of  Test  Site(s) 

15.  How  well  do  you  feel  NOHIMS  has  been  integrated  into  the  day-to-day 
procedures  of  the  (your)  test  site(s)? 

very  well/ 
somewhat  well/ 
somewhat  poorly/ 
poorly. 

16.  How  well  do  you  feel  that  NOHIMS  has  responded  to  the  particular 
needs  of  the  (your)  test  site(s)? 

very  well/ 
somewhat  well/ 
somewhat  poorly/ 
poorly . 

17.  Were  there  needs  specific  to  the  (vour)  test  site(s)  that  NOHIMS 
could  not  meet?  If  so,  what  were  those  needs? 
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ACCEPTABILITY  OF  NOHIMS  TO  USERS 

1.  In  general,  I  feel  that  NOHIMS 

adequately/ 
somewhat  adequately/ 
somewhat  inadequately/ 
inadequately/ 

performs  the  functions  that  are  required  in  my  work. 

2.  Generally,  I  feel  that  NOHIMS  is 

reliable/ 

somewhat  reliable/ 
somewhat  unreliable/ 
unreliable . 

3.  Generally,  I  feel  that  NOHIMS 

is/ 

is  somewhat/ 
is  somewhat  not/ 
is  not/ 

user  friendly  and  easy  to  operate. 

4.  In  general,  the  data  collection  forms  are 

acceptable/ 
somewhat  acceptable/ 
somewhat  unacceptable/ 
unacceptable/ 

to  me. 

5.  In  general,  I  think  that  the  data  collection  forms  are 

acceptable/ 
somewhat  acceptable/ 
somewhat  unacceptable/ 
unacceptable/ 

to  the  patient/worker . 

6.  I  feel  that  the  changes  in  procedures  required  by  NOHIMS  are 

acceptable/ 
somewhat  acceptable/ 
somewhat  unacceptable/ 
unacceptable . 

7.  I  feel  that  NOHIMS 

is  an  aid  in/ 
is  somewhat  of  an  aid  in/ 
has  no  effect  on/ 
is  somewhat  of  a  hindrance  in/ 
is  a  hindrance  in/ 

the  provision  of  care  to  the  pat i ent /worker . 


(Medical  users  only)  T  feel  that  NOHIMS  has 

significantly  disrupted/ 
somewhat  disrupted/ 
not  disrupted/ 

traditional  patterns  of  clinical  thinking  and/or  patient  management 

NOHIMS  has  affected  my  workload  by 

significantly  increasing  my  workload/ 
somewhat  increasing  my  workload/ 
somewhat  decreasing  my  workload/ 
significantly  decreasing  my  workload/ 
changing  the  nature  of  my  workload/ 
no  effect  on  my  workload. 

NOHIMS  features  that  have  been  incorporated  into  m^  everyday  work 
procedures  include 

data  collection  forms/ 
data  entry/ 

on-line  look-up/interactive  query/interactive  flowcharts/ 

display  of  standard  reports/ 

printed  standard  reports/ 

report  generation/ 

other : 


These  features  have  made  my  job 

much  easier/ 
somewhat  easier/ 
no  effect/ 
somewhat  harder/ 
much  harder. 

These  features  have  made  me 

less  productive/ 
about  as  productive/ 
more  productive. 

Generally,  I  feel  that  system  users  can  perform  their  jobs 

more  efficiently  and  effectively/ 

somewhat  more  efficiently  and  effectively/ 

to  the  same  level  of  efficiency  and  effectiveness/ 

somewhat  less  efficiently  and  effectively/ 

less  efficiently  and  effectively/ 

because  of  NOHIMS. 

In  general,  my  assessment  of  how  well  people  have  adapted  to 
NOHIMS  is  that  they  have  adapted 

well/ 

somewhat  well/ 
somewhat  poorly/ 
poorly. 
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Overall,  NOHIMS  is 

acceptable/ 
somewhat  acceptable/ 
somewhat  unacceptable/ 
unacceptable . 

If  NOHIMS  is  unacceptable  or  somewhat  unacceptable,  what  changes 

need  to  be  made  in  order  to  make  it  acceptable? 

less  data  have  to  be  collected/ 

more  data  have  to  be  collected/ 

data  have  to  be  collected  at  more  points/ 

changes  to  data  collection  forms  are  required/ 

data  have  to  be  stored  longer/ 

more  hardware  is  required/ 

more  communication  gear  is  required/ 

more  software  is  required/ 

changes  to  present  software  are  required/ 

new  report  formats  are  required/ 

new  reports  are  required/ 

inquiry  capability  is  required/ 

more  inquiry  capability  is  required/ 

more  system  support  is  required/ 

more  training  is  required/ 


other: 
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ASSESSMENT  OF  TRANSFERABILITY  OF  NOHIMS  TO  OTHER  NAVY  INDUSTRIAL  SITES 

1.  My  assessment  of  the  suitability  of  NOHIMS  to  the  information 
processing  needs  of  other  Navy  industrial  sites  is  that  NOHIMS  is 

very  suitable/ 
somewhat  suitable/ 
somewhat  unsuitable/ 
very  unsuitable. 

2.  My  opinion  of  the  flexibility  and  adaptability  of  NOHIMS  is  that 
NOHIMS  is 

adequately  flexible  and  adaptable/ 
somewhat  adequately  flexible  and  adaptable/ 
somewhat  inadequately  flexible  and  adaptable/ 
inadequately  flexible  and  adaptable/ 

to  be  transferred  to  other  Navy  industrial  sites. 

3.  Areas  in  which  NOHIMS  needs  to  be  more  flexible  and  adaptable 
include : 


4.  My  assessment  of  the  ease  of  transfer  of  NOHIMS  to  other  Navy 
industrial  sites  is  that  the  process  will  be 

difficult/ 
somewhat  difficult/ 
somewhat  easy/ 
easy . 

5.  The  specific  problems  I  foresee  in  transferring  NOHIMS  to  other 
Navy  industrial  sites  are  that 


6.  It  is  my  opinion  that  the  acceptability  of  NOHIMS  among  users  at 
other  Navy  industrial  sites  will  be 

very  high/ 
high/ 

somewhat  high/ 
somewhat  low/ 
low  / 

very  low. 
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PERCEIVED  BENEFITS  OF  NOHIMS 

1.  In  my  opinion,  the  benefits  of  NOHIMS  have  been 

increased  quality  of  care  provided  to  the  worker/patient  through: 
fewer  unnecessary  tests  and  ancillary  services/ 
fewer  unnecessary  examinations/visits/ 
appropriateness  of  tests  performed/ 
reduced  waiting  time/ 
more  accurate  patient  medical  record/ 
timely  and  perpetual  access  to  data/ 
earlier  diagnosis  of  illnesses/conditions/ 
earlier  notification  of  abnormal  test  results/f indings/ 
base-line  data  on  the  health  of  an  employee/ 
increased  compliance  with  monitoring  programs/ 
reduction  in  occupational  exposures  to  hazardous  agents/ 
improved  workplace  monitoring/ 

better  identification  of  possible  hazards/ 
better  identification  of  workers  exposed/ 
safer  working  conditions/ 
improved  job  certification  program/ 
increased  confidence  of  workers/ 

improved  communication  between  those  concerned  with 
the  occupational  health  of  the  worker/ 
increased  productivity  of  staff /cl inics/ 
increased  efficiency  in  the  use  of  resources/ 
savings  in  manpower/ 

reduction  in  the  cost  of  providing  services/ 
improved  planning  and  budgeting/ 
more  accurate  administrative  reports/ 

more  accurate/available  database  for  research  efforts/ 
other  health  care  benefits: 


other  monitoring  benefits: 


other  administrative  benefits: 


other  benefits: 


2.  Of  those  mentioned,  the  most  significant  benefit  of  NOHIMS  is 


3.  The  costs  of  implementing  and  operating  NOHIMS 

clearly  exceed  or  outweigh  the  benefits/ 
somewhat  exceed  or  outweigli  the  benefits/ 
equal  the  benefits/ 

or  the  benefits 

somewhat  exceed  or  outweigh  the  costs/ 
clearly  exceed  or  outweigh  the  costs. 
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SUITABILITY  OF  GOVERNMENT-OWNED  OCCUPATIONAL  HEALTH  INFORMATION  SYSTEMS  TO 
NAVY  NEEDS 

1.  What  government -owned  occupational  health  information  systems  exist? 
What  is  their  current  development  status? 

Department  of  Transportation - Voluntary  Employee  Injury/ 

Illness  Reporting  System  (VEIIRS)/ 

Coast  Guard - acquired  contract  services  to  study  problem/ 

Environmental  Protection  Agency - Injury  Reporting  and 

Information  System  (IRIS)/ 

U.S.  Army - has  initiated  system  development  efforts/ 

U.S.  Air  Force - Computerized  Occupational  Health  Program 

currently  awaiting  development  funds/ 

Other:  _ . 

2.  For  each  system,  check  off  the  features/capabilities  required  by  Navy 
information  processing  needs  that  the  government -owned  systems  have. 


DOT  Coast  EPA  U.S.  U.S.  Air 
VEIIRS  Guard  IRIS  Army  Force 


Required  information  is  collected: 
personnel  data 


hazardous  materials 
characteristics 


presence  of  hazardous 
materials 


data  on  health  of  workers: 
illness  and  injuries 


sick  leave/absenteeism 


routine  examinations 


test  results 


procedures 


medical  histories 


mortality  data 


Not  familiar  with  system 


Somewhat  suitable 


Somewhat  unsuitable 


Very  unsuitable 


5.  My  assessment  of  the  suitability  of  each  of  the  government -owned 
systems  to  Navy  information  manipulation  needs  is  that  they  are 


(  • 

DOT  Coast  EFA 

'  VEIIRS  Guard  ;  IRIS 

U.S. 

Army 

U.S.  Air 
Force 

Very  suitable 

Somewhat  suitable 

Somewhat  unsuitable 

,  ■ 

Very  unsuitable  \  j 
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6.  Overall,  my  assessment  ui  me  auuijiutcy  01  eacn  oi  cue  government- 
owned  systems  to  Navy  information  processing  needs  is  that  they  are 


Very  adequate 
Adequate 

Somewhat  adequate 
Somewhat  inadequate 
Inadequate 
Very  inadequate 


DOT 

VEIIRS 

Coast 

Guard 

EPA 

IRIS 

u.s. 

Army 

U.S.  Air 
Force 

i 

\ 

_ 
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SUITABILITY  OF  COMMERCIALLY  AVAILABLE  OCCUPATIONAL  HEALTH  INFORMATION  SYSTEMS 
TO  NAVY  NEEDS 

1.  What  commercial  occupational  health  information  systems  are 
available? 

Computerized  Occupational  Health  and  Environmental 
Surveillance  System  (COHESS)/ 

FLOW  GEMINI  [Flow  GEneral's  Medical  Information 
Needs  for  Industry]  (FG) / 

DEChealth  (DEC)/ 

Other:  _ _ 

Other: _ _ _ . 

2.  For  each  system,  check  off  the  features/capabilities  required  by  Navy 
information  processing  needs  that  the  commercial  systems  have. 


COHESS  [  FG 


Required  information  is  collected: 
personnel  data 

hazardous  materials 
characteristics 

presence  of  hazardous 
materials 

data  on  health  of  workers: 
illness  and  injuries 

sick  leave/absenteeism 


routine  examinations 


test  results 


procedures 


medical  histories 


mortality  data 


individual  exposures/ 
exposure  history 

data  on  acc idents/ incidents 

occupational  histories 

other 
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3.  My  assessment  of  the  suitability  of  each  of  the  commercial  svstems 
to  Navy  information  collection  needs  is  that  they  are 


COHESS 

FG 

DEC 

Other 

Other 

Very  suitable 

Somewhat  suitable 

Somewhat  unsuitable 

Very  unsuitable 

4.  My  assessment  of  the  suitability  of  each  of  the  commercial  systems 
to  Navy  information  retrieval  needs  is  that  they  are 


COHESS 

FG 

Very  suitable 

Somewhat  suitable 

Somewhat  unsuitable 

Very  unsuitable 

DEC 


Other 


Other 


5.  My  assessment  of  the  suitability  of  each  of  the  commercial  systems 
to  Navy  information  manipulation  needs  is  that  they  are 


COHESS 

Very  suitable 

Somewhat  suitable 

- - 

Somewhat  unsuitable 

Other  :  Other 


Very  unsuitable 
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DESCRIPTION  OF  NAVY  INTERIM  OCCUPATIONAL  HEALTH  INFORMATION  SYSTEM/SUITABILITY 
OF  NAVY  INTERIM  OCCUPATIONAL  HEALTH  INFORMATION  SYSTEM  TO  NAVY  NEEDS 


37A  1.  Check  off  the  features/capabilities  required  by  Navy  information 

processing  needs  that  the  Navy  interim  system  has. 


Navy  Interim  System 


Required  information  is  collected: 
personnel  data 


hazardous  materials 
characteristics 


presence  of  hazardous 
materials 


data  on  health  of  workers: 
illness  and  injuries 


Data  can  be  retrieved  in  required 
formats : 


Navy  Interim  System 


tables  of  hazardous  materials 

lists  of  workers  with 
exposures 

lists  of  workers  requiring 
physical  examinations 

medical  encounter  reports 

medical  summary  reports 

management  reports 

other 

Data  can  be  manipulated  in  required 
ways : 

number  of  surveys  conducted 

. .  .  .  _  _  .  .  .  .  i 

number  of  persons  exposed  to 
hazard 

number  of  examinations 
conducted 

l  - 

number  of  laboratory  tests 
done 

number  of  radiographs  done 

number  of  asbestos  exami¬ 
nations  conducted 

list  of  those  with  ordered 
but  unresulted  tests 

other 

Other 

Not  familiar  with  interim  system* 

If  not  familiar  with  the  interim  system, 
go  to  the  next  interview  section. 
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2.  What  are  the  software  quality  attributes  of  the  interim  system? 

Does  the  interim  system  allow  performance  of  all 
required  tasks? 

identification  tasks/ 
entry  tasks/ 
review  tasks/ 
editing  tasks/ 

information  retrieval  tasks/ 
system  maintenance  tasks. 

Is  the  interim  system  reliable? 

What  error  recovery  procedures  does  the  interim  system  have? 
What  back-up  procedures  are  required  to  prevent  data  loss? 

What  features  make  the  source  program  code  efficient? 

How  portable  and  hardware  independent  is  the  interim  system? 
How  maintainable  is  the  interim  system  software? 

3.  What  are  the  operational  characteristics  of  the  interim  system? 

How  well  does  the  interim  system  present  its  operational 
capabilities  to  the  user? 

Is  the  interim  system  "menu  driven"  at  all  selection  levels? 

What  user  on-line  assistance  functions  does  the  interim 
system  have? 

What  error  diagnostic  features  and  debugging  aids  does 
the  interim  system  have? 

What  database  manager  utilities  does  the  interim  system  have? 
What  is  the  average  entry  time  per  input  form? 

What  are  the  add,  save,  change,  and  delete  procedures? 

Does  the  interim  system  have  a  search  in  context  capability? 
What  are  the  general  filing  procedures  for  the  interim  system? 
Can  data  and  routines  be  downloaded  to  magnetic  tape? 

4.  What  security  features  does  the  interim  system  have? 


5.  What  are  the  software  support  requirements  for  the  interim  system? 

What  and  how  many  support  personnel  are  required  to  maintain 
the  interim  system  software? 

What  functions  must  be  performed  by  the  support  personnel? 

What  is  the  estimated  amount  of  support  manhours  required 
per  month  to  maintain  the  Interim  system? 
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37A  6.  What  system  support  is  available  for  the  interim  system? 

What  kind  of  support  is  available  for  the  initial  training 

of  users? 

V 

What  kind  of  support  is  available  for  ongoing  and  update 
training  of  users? 

What  kind  of  support  is  available  for  technical  concerns? 

What  kind  of  documentation  and  job  aids  are  there  that 
support  system  operations? 

7.  What  system  scenarios  are  required  to  maintain  the  interim  system? 

What  prime  time  maintenance  functions  must  be  performed 
during  the  day  on  a  daily  basis? 

What  system  maintenance  functions  must  be  performed  during 
the  off-shift  on  a  regular  basis?  How  often  must  these 
tasks  be  performed? 

How  often  must  patient  files  be  archived? 

8.  What  are  the  organizational  requirements  of  the  interim  system? 

What  requirements  are  there  for  users  of  the  interim  system 
to  have  programming  skills?  for  system  managers? 

What  requirements  are  there  for  system  managers  to  understand 
source  code? 

What  staff  is  required  to  operate  an  interim  system  installa¬ 
tion? 

What  requirements  are  there  for  the  installation  area? 
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9.  What  is  the  minimum  hardware  configuration  that  could  support 
the  interim  system? 


37B  10.  My  assessment  of  the  suitability  of  the  Navy  interim  system  to  Navy 

information  collection  needs  is  that  it  is 

very  suitable/ 
somewhat  suitable/ 
somewhat  unsuitable/ 
very  unsuitable. 

37B  11.  My  assessment  of  the  suitability  of  the  Navy  interim  system  to  Navy 

information  retrieval  needs  is  that  it  is 

very  suitable/ 
somewhat  suitable/ 
somewhat  unsuitable/ 
very  unsuitable. 
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378  12.  My  assessment  of  the  suitability  of  the  Navy  interim  system  to  Navy 
information  manipulation  needs  is  that  it  is 

very  suitable/ 
somewhat  suitable/ 
somewhat  unsuitable/ 
very  unsuitable. 

37B  13.  Overall,  my  assessment  of  the  adequacy  of  the  Navy  Interim  system 
to  Navy  information  processing  needs  is  that  i t  is 

very  adequate/ 
adequate/ 

somewhat  adequate/ 
somewhat  inadequate/ 
inadequate/ 
very  inadequate . 
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APPENDIX  B 

INTERVIEWS  CONDUCTED 


Person  Interviewed/Title/Location 

CDR.  JAMES  W.  ALLEN 
NOHIMS  Project  Manager 
Navy  Environmental  Health  Center 
Norfolk,  Virginia 

MARGIE  ACOL 

Occupational  Health  Technician 

Occupational  Health  Unit 

North  Island,  San  Diego,  California 

DONALD  D.  BECK 
Consultant 

Paso  Robles,  California 
ROGER  BECKETT 

Head,  Industrial  Hygiene  Division 
Naval  Hospital 
Bremerton,  Washington 

C.  W.  BOLLINGER,  M.D. 

Director,  Occupational  and 

Environmental  Health  Services 
Naval  Hospital 
Bremerton,  Washington 

LARRY  BRADY 

Industrial  Hygienist 

Naval  Air  Rework  Facility 

North  Island,  San  Diego,  California 

PAT  BROWNE 

Administrative  Services  Officer/ 
Assistant  to  Production  Department  Head 
Naval  Air  Rework  Facility 
North  Island,  San  Diego,  California 

ANDREW  BRYSON 

Head,  Environmental  Health  Division 
Occupational  Health  and  Preventive 
Medicine  Department 
San  Diego,  California 


Interview  Guide  Used 


NEHC  Project  Management  Team 


Medical  Care  Provider  User 


N11RC  InLeriin  System  Developer 


Higher  Level  Navy  Management 


Medical  Care  Provider  User 
Test  Site  Administrator 


Navy  Legal  Counsel 
Industrial  User  (Hygienist) 


Navy  Legal  Counsel 


Higher  Level  Navy  Management 


MERLE  BUNDY,  M.D. 

Head,  Occupational  Medicine  Division 
Occupational  Health  and  Preventive 
Medicine  Department 
San  Diego,  California 

ANNE  BURTON 
Industrial  Hygienist 
Occupational  Health  and  Preventive 
Medicine  Department,  Industrial 
Hygiene  Division 

North  Island,  San  Diego,  California 

RICHARD  COHEN,  M.D. 

Head 

Occupational  Health  Unit 

North  Island,  San  Diego,  California 

JENNY  EARLY 

Occupational  Health  Technician 

Occupational  Health  Unit 

North  Island,  San  Diego,  California 

STEVE  GRABOWSKI,  M.D. 

Occupational  Medical  Officer 

Occupational  Health  Unit 

North  Island,  San  Diego,  California 

E.  K.  ERIC  GUNDERSON,  Ph.D. 

Head,  Environmental  Medicine  Dept 
Naval  Health  Research  Center 
San  Diego,  California 

CAPT.  C.  W.  HALVERSON 

Head,  Occupational  Health  and 

Preventive  Medicine  Department 
San  Diego,  California 

BILL  HAROLD 

Peripheral  Equipment  Operator 

Occupational  Health  Unit 

North  Island,  San  Diego,  California 

JAMES  C.  HELMKAMP,  M.D. 

Research  Epidemiologist 
Naval  Health  Research  Center 
San  Diego,  California 


Higher  Level  Navy  Management 
Medical  Care  Provider  User 


Test  Site  Administrator 
Industrial  User  (Hygienist) 


Test  Site  Administrator 
Medical  Care  Provider  User 


Medical  Care  Provider  User 


Medical  Care  Provider  User 


NIIRC  Interim  System  Developer 
N1IRC  NOHIMS  Developer 


Higher  Level  Navy  Management 


Data  Entry  Personnel 


NIIRC  NOHIMS  Developer 


CAPT.  TOM  HENN 

Head,  Occupational  Health  and 
Preventive  Medicine  Department 
Naval  Hospital 
Bremerton,  Washington 

LARRY  HERMANSEN 
Systems  Analyst 
Naval  Health  Research  Center 
San  Diego,  California 

PETE  HOWARD 
Industrial  Hygienist 
Naval  Hospital 
Bremerton,  Washington 

MIKE  JACKSON 
NOHIMS  Site  Manager/ 

Industrial  Hygienist 
Naval  Hospital 
Bremerton,  Washington 

GERALD  JOCHEM 

Administrator,  Injury  Compensation 
Program 

Naval  Air  Station/Naval  Air  Rework 
Facility 

North  Island,  San  Diego,  California 

LARRY  KALCSO 
Industrial  Hygienist 
Naval  Hospital 
Bremerton,  Washington 

ROY  KENNON,  M.D. 

Occupational  Physician 

Occupational  Health  Unit 

North  Island,  San  Diego,  California 

SUSAN  LANCASTER 
Compensation  Specialist 
Civilian  Personnel 
Naval  Hospital 
San  Diego,  California 

MICHAEL  LEMM 
NOHIMS  Site  Manager 
Occupational  Health  and  Preventive 
Medicine  Department 
San  Diego,  California 


Free  form  interview 

NIIRC  Interim  System  Developer 
NIIRC  NOHIMS  Developer 
ADP  I’ersonnel 
NOHIMS  System  Manager 


Industrial  User  (Hygienist) 


NOHIMS  System  Manager/Test 
Site  Administrator 
ADP  Personnel 


Navy  Legal  Counsel 


Industrial  User  (Hygienist) 


Medical  Care  Provider  User 


Navy  Legal  Counsel 


Higher  Level  Navy  Management 
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BONNIE  NELSON,  P.A. 

Physician's  Assistant 

Occupational  Health  Unit 

North  Island,  San  Diego,  California 

JAN  PEARSON 
Clerk  Typist 
Naval  Hospital 
Bremerton,  Washington 

WILLIAM  M.  PUGH 

Head,  Medical  Information  Systems 
Program 

Naval  Health  Research  Center 
San  Diego,  California 

LYNNE  PUGSLEY 

Employee  Relations  Specialist 
Civilian  Personnel 
San  Diego,  California 

VERNA  RAGER 

Adminstrative  Services  Officer 

Naval  Air  Rework  Facility 

North  Island,  San  Diego,  California 

MATT  ROSA 

Safety  and  Health  Manager 
Naval  Air  Rework  Facility 
North  Island,  San  Diego,  California 

BETTY  WJIITEAKER 
Industrial  Hygienist 
Occupational  Health  and  Preventive 
Medicine  Department,  Industrial 
Hygiene  Division 

North  Island,  San  Diego,  California 


Medical  Care  Provider  User 


Data  Entry  Personnel 


NHRC  Interim  System  Developer 
NHRC  NOHIMS  Developer 
ADP  Personnel 


Naval  Hospital 
Navy  Legal  Counsel 


Navy  Legal  Counsel 


Navy  Legal  Counsel 

Higher  Level  Navy  Management 


Industrial  User  (Hygienist) 


